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Abstract 

We present a new approach for reasoning about liveness properties of distributed systems, 
represented as automata. Our approach is based on simulation relations, and requires reasoning 
only over finite execution fragments. Current simulation-relation based methods for reasoning 
about liveness properties of automata require reasoning over entire executions, since they in- 
volve a proof obligation of the form: if a concrete and abstract execution "correspond" via the 
simulation, and the concrete execution is live, then so is the abstract execution. 

Our contribution consists of (1) a formalism for defining liveness properties, (2) a proof 
method for liveness properties based on that formalism, and (3) two expressive completeness 
results: firstly, our formalism can express any liveness property which satisfies a natural "robust- 
ness" condition, and secondly, our formalism can express any liveness property at all, provided 
that history variables can be used. 

To define liveness, we generalize the notion of a complemented-pairs (Streett) automaton 
to an infinite state-space, and an infinite number of complemented-pairs. Our proof method 
provides two main techniques: one for refining liveness properties across levels of abstraction, 
and the other for refining liveness properties within a level of abstraction. The first is based 
on extending simulation relations so that they relate the liveness properties of an abstract (i.e., 
higher level) automaton to those of a concrete (i.e., lower level) automaton. The second is based 
on a deductive method for inferring new liveness properties of an automaton from already estab- 
lished liveness properties of the same automaton. This deductive method is diagrammatic, and 
is based on constructing "lattices" of liveness properties. Thus, it supports proof decomposition 
and separation of concerns. 



1 Introduction and Overview 



One of the major approaches to the construction of correct distributed systems is the use of an 
operational specification, e.g., an automaton or a labeled transition system, which is successively 
refined, via several intermediate levels of abstraction, into an implementation. The implementation 
is considered correct if and only if each of its externally visible behaviors, i.e., traces, is also a trace 
of the specification. This "trace inclusion" of the implementation in the specification is usually 
established transitively by means of establishing the trace inclusion of the system description at 
each level of abstraction in the system description at the next higher level. When reasoning at any 
particular level, we call the lower level the concrete level, and the higher level the abstract level. 

The correctness properties of a distributed system are classified into safety and liveness [27]: 
safety properties state that "nothing bad happens," for example, that a database system never 

^Some of the results in this paper appeared in the eighteenth ACM Symposium on Principles of Distributed 
Computing, (PODC'99), under the title "Liveness-preserving Simulation Relations". 
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produces incorrect responses to queries, while livencss properties state that "progress occurs in the 
system," for example, every query sent to a database system is eventually responded to. Safety 
properties are characterized by the fact that they are violated in finite time: e.g., once a database 
has returned an incorrect response to an external user, there is no way to recover to where the 
safety property is satisfied. Liveness properties, on the other hand, arc characterized by the fact 
that there is always the possibility of satisfying them: the database always has the opportunity 
of responding to pending queries. Thus, an operational specification defines the required safety 
properties by means of an automaton, or labeled transition system. The reachable states and 
transitions of the automaton are the "good" states/transitions, whose occurrence does not violate 
safety. Any unreachable states, if present, arc "bad," i.e., they represent a violation of the safety 
properties, e.g., due to a fault. The occurrence of such a "bad" state is something that happens 
in finite time, and so constitutes the violation of a safety property. The liveness properties are 
specified by designating a subset of the executions of the automaton as being the "live" executions, 
leading to the notion of live execution property. These are the executions along which eventTially, 
all the necessary actions are executed, e.g., the actions that respond to pending queries. To express 
the idea that there is always the possibility of satisfying a liveness property, this subset of the 
executions must have the property that any finite execution can be extended to an execution in 
the subset [1]. 

Distributed systems consist of many sequential processes which execute concurrently. To reason 
effectively about such large systems, researchers have proposed the use of compositional reasoning: 
global properties of the entire system are inferred by first deducing local properties of the con- 
stituent processes or subsystems, and then combining these local properties to establish the global 
properties. In particular, we desire that refinement is compositional: when a particular process Pi 
is refined to a new process P/, we wish to reason only about whether is a correct refinement of 
Pi, without having to engage in global reasoning involving all of the other processes in the system. 
The need for compositional reasoning, as well as notions such as behavioral subtyping [30] and 
information hiding, motivated the development of the notion of externally visible behavior, e.g., 
the set of traces of an automaton, where a trace is a sequence of "external" actions, visible at the 
interface, which the automaton can engage in. Typically, a trace is obtained by taking an execution 
and removing all the internal information, i.e., the states and the internal actions. 

The notion of externally visible behavior then leads naturally to notions of external safety 
and liveness properties, which are specified over the traces of an automaton, rather than over the 
(internal) states and executions. The external safety property is the set of all traces, since this is 
the external "projection" of all the executions, which define the reachable states and transitions, 
which in turn give us the safety properties, as discussed above. The external liveness property is 
obtained by taking the traces of all the live executions. These are called the live traces, and the set 
of all live traces is a live trace property. 

Trace inclusion usually means that every trace of the concrete automaton is a trace of the 
abstract automaton. Thus, trace inclusion deals with safety properties: every safety property of 
the set of traces of the concrete automaton is also a safety property of the set of traces of the abstract 
automaton. Thus, external safety properties are preserved by the refinement from the abstract to 
the concrete. Trace inclusion does not address liveness properties, however. The appropriate notion 
of inclusion for external liveness properties is live trace inclusion [17, 18]: every live trace of the 
concrete automaton is a live trace of the abstract automaton. 

Consider again the database example, with the external liveness property that every query 
submitted is eventually processed. Let B be a high-level specification of such a system. By using 
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state variables that record requests and responses, this property can be easily stated in terms of the 
executions of B, which results in a live execution property. The set of traces of the live executions 
then gives the corresponding live trace property. Provided that the state variables which record 
requests and responses are updated correctly, the live trace property will only contain traces in 
which every input of a query to the database (e.g., from an external "user") is eventually followed 
by an output of a response from the database (to the user). 

Let A be an implementation of B. The live executions of A arc defined by the liveness proper- 
ties that typically can be guaranteed by reasonable implementations, e.g., "fair scheduling" [15] — 
every continuously enabled action (or process) is eventually executed, and fair polling of message 
channels — every message sent is eventually received^. The set of traces of the live executions then 
gives the live trace property corresponding to this action/process fairness and reliable message de- 
livery in the underlying execution behavior. However, the live trace property that we wish to verify 
for A is not this property per se, but the same live trace property which B has, namely that every 
input of a query to the database is eventually followed by an appropriate output from the database. 
This paper addresses the problem of verifying such liveness properties for an implementation A. 

It is clear that verifying that the live traces of A are contained in the live traces of B immediately 
yields the desired conclusion, namely that A has the desired live trace property. Thus, live trace 
inclusion applied to the above example implies that every trace of an execution of A in which 
all messages sent are eventually received, and all continuously enabled actions (processes) are 
eventually executed, i.e., a live trace of A, is also a live trace of B, i.e., a trace in which all 
queries receive a response. This is exactly what is required, since the liveness properties of A along 
executions where, for example, messages sent are not received, are not of interest. Conversely, a 
live execution of A, in which all messages sent are received, and scheduling is fair, should produce 
an external behavior which has the desired liveness properties: every query receives a response. 
More generally, live trace inclusion implies that external liveness properties are preserved by the 
refinement from the specification B to the implementation A. 

One of the main proof techniques for establishing trace inclusion is that of establishing a simu- 
lation [34] or bisimulation [43] between the concrete and the abstract automata. A simulation (or 
bisimulation) establishes a certain correspondence (depending on the precise type of simulation) 
between the states/transitions of the concrete automaton and the states/transitions of the abstract 
automaton, which then implies trace inclusion. An important advantage of the simulation-based 
approach is that it only requires reasoning about individual states and finite execution fragments, 
rather than reasoning about entire (infinite) executions. Unfortunately, the end-result, namely the 
establishment of trace inclusion, does not, as we establish in the sequel, imply live trace inclusion, 
since the set of live traces is, in general, a proper subset of the set of traces. 

Our contributions. In this paper, we show how to use simulation relations to reason about 

liveness. Our approach uses a state-based technique to specify live execution properties: a liveness 
condition is given as a (possibly infinite) set of ordered pairs (Redj, Greerij), where Redj, Greerij 
are sets of states. An execution is considered to satisfy a single pair (Red, Green) iff whenever 
it contains infinitely many states in Red, then it also contains infinitely many states in Green. 
An execution is live iff it satisfies all the pairs in the liveness condition. A trace is live iff it 
is the trace of some live execution. Our notion of liveness condition is akin to the acceptance 
condition of a complem,ented-pairs (or Streett) automaton [4, 13, 20], except that we allow an 

^We do not address fault-tolerance for the time being, thus messages are always received along a live execution. 
See Section 7.2 for a discussion of how the techniques presented in this paper can be applied to fault-tolerance. 
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infinite number of pairs, and also our automata can have an infinite number of states and transitions. 
We tlien present the notion of liveness-preserving simulation relation, which appropriately relates 
the states mentioned in the concrete automaton's liveness condition to those mentioned in the 
abstract automaton's liveness condition. This is done in two stages. The first stage refines the 
liveness condition of the abstract automaton into a "derived" liveness condition of the concrete 
automaton. This derived condition may contain complemented-pairs that are not directly specified 
in the liveness condition of the concrete automaton. The second stage then proves that the derived 
condition is implied by the directly specified liveness condition of the concrete automaton (using a 
"lattice" construction). The use of such a derived liveness condition allows us to break down the 
refinement problem at each level into two simpler subproblcms, since the derived liveness condition 
of the concrete automaton can usually be formulated to better match with the liveness condition 
of the abstract automaton. Establishing a liveness-preserving simulation relation then allows us 
to conclude that every live trace of the concrete automaton is also a live trace of the abstract 
automaton. As discussed above, our method can be applied to multiple levels of abstraction, 
where the specification is successively refined in stages, producing several intermediate descriptions 
of the specified system, until a description that is directly implementable on the desired target 
architecture and has adequate performance and fault-tolerance properties is derived. Thus, we 
address the problem of preserving liveness properties in the successive refinement of a specification 
into an implementation, which contributes to making the method scalable, as our extended example 
in Section 6 shows. 

We establish two expressive completeness results for complemented-pairs liveness conditions. 
The first shows that any live execution property which satisfies a natural "robustness" condition can 

be specified by a complemented-pairs liveness condition. The second shows that any live execution 
property whatsoever can be specified by a complemented-pairs liveness condition, provided that 
history variables can be used. 

The paper is organized as follows. Section 2 provides technical background on automata and 
simulation relations from [17] and [34]. Section 3 gives our key technical notion of a live automaton, 
i.e., an automaton equipped with a liveness condition, and also defines live executions, live traces, 
and derived liveness properties. Section 4 presents our definitions for liveness-preserving simulation 
relations, and shows that liveness-preserving simulation relations imply live trace inclusion. Sec- 
tion 5 shows how a derived liveness condition can be deduced from the directly specified condition. 
Together, these two sections give our method for refining liveness properties. Section 6 applies our 
results to the eventually-serializable data service of [14, 26]. Section 7 examines some alternative 
choices for expressing liveness, shows that our method can also be applied to fault-tolerance proper- 
ties, and briefly discusses the mechanization of our method. Section 8 discusses the expressiveness 
of complemented-pairs for liveness properties, and presents two relative completeness results. Sec- 
tion 9 discusses related work. Finally, Section 10 presents our conclusions and discusses avenues 
for further research. Appendix A gives some background on simulation relations. Appendix B gives 
some background on temporal logic, and Appendix C presents I/O automaton pseudocode for the 
eventually-serializable data service of [14, 26]. 

2 Technical Background 

The definitions and theorems in this section are taken from [17] and [34], to which the reader is 
referred for details and proofs. 
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2.1 Automata 



Definition 1 (Automaton) An automaton A consists of four components: 

1. a set states (A) of states, 

2. a nonempty set start (A) C states (A) of start states, 

3. an action signature sig{A) = {ext{A),int{A)) where ext{A) and int{A) are disjoint sets of 
external and internal actions, respectively (let acts (A) denote the set ext{A) U int{A)), and 

4- a transition relation steps (A) C states (A) x acts {A) x states (A). 

Let s, s', u, u',. . . range over states and a,b,... range over actions. Write s -^a s' iff (s, a, s') G 
steps (A). Wc say that a is enabled in s. An execution fragment a of automaton A is an alternating 
sequence of states and actions SQaiSia2S2 ■ ■ ■ such that (sj, Oj+i, Sj+i) G steps{A) for all i > 0, i.e., 
a conforms to the transition relation of A. Furthermore, if a is finite then it ends in a state. If a 
is an execution fragment, then fstate{a) is the first state along a, and if a is finite, then lstate{a) 
is the last state along a. If ai is a finite execution fragment, 02 is an execution fragment, and 
lstate{ai) = fstate{a2), then ai'~~a2 is the concatenation of ai and 02 (with lstate{ai) repeated 
only once). Let a = soaiSia2S2 ... be an execution fragment. Then the length of a, denoted \a\, is 
the number of actions in a. \a\ is infinite if a is infinite, and \a\ = if a consists of a single state. 

df 

Also, a\i = sgaisi . . . aiSi. If a is a prefix of a', we write a < a'. We also write a < a' for a < a' 
and a ^ a' . 

An execution of A is an execution fragment that begins with a state in start {A). The set of 
all executions of A is denoted by execs (A), and the set of all infinite executions of A is denoted 
by execs'^ {A). A state of A is reachable iff it occurs in some execution of A. The trace trace{a) 
of execution fragment a is obtained by removing all the states and internal actions from a. The 
set of traces of an automaton A is defined as the set of traces (3 such that (5 is the trace of some 
execution of A. It is denoted by traces{A). If (/? is a set of executions, then traces (ip) is the set 
of traces (3 such that (3 is the trace of some execution in ip. If a is an action, then we define 
trace{a) = a if a is external, and trace{a) = A (the empty sequence) if a is internal. If 0102 ■ ■ ■ a„ is 
a sequence of actions, then trace{ai ■ ■ ■ an) = trace{ai)trace{a2) ■ ■ ■ trace{an), where juxtaposition 
denotes concatenation. 

If is a relation over Si x 52 (i.e., R C. Si x S2) and si € Si, then we define R[si] = 
{s2 I (si, S2) G R}- We use \ to denote the restriction of a mapping to a subset of its domain. 

2.2 Simulation Relations 

We shall study five different simulation relations: forward simulation, refinement mapping, back- 
ward simulation, history relation, and prophecy relation. These relations all preserve safety prop- 
erties. In Section 4, we extend these simulation relations so that they preserve liveness as well 
as safety. A forward simulation requires that (1) each execution of an external action a of ^ is 
matched by a finite execution fragment of B containing a, and all of whose other actions are internal 
to B, and (2) each execution of an internal action of A is matched by a finite (possibly empty) 
execution fragment of B all of whose actions are internal to B (if the fragment is empty, then we 
have u G f[s'], i.e., u and s' must be related by the simulation). It follows that forward simulation 
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implies trace inclusion (also referred to as the safe preorder below), i.e., if there is a forward simu- 
lation from A to B, then traces (A) C traces {B). Likewise, the other simulation relations all imply 
trace inclusion (the backward simulation and prophecy relation must be image-finite) for similar 
reasons. See Lemma 6.16 in [17] for a formal proof of this result. 

We use F, R, iB, H, iP to denote forward simulation, refinement mapping, image-finite backward 
simulation, history relation, image-finite prophecy relation, respectively. Thus, when we write 
X G {F, R, iB, H, iP}, we mean that X is one of these relations. We write A <p B if there exists a 
forward simulation from Ato B w.r.t. some invariants, and A <f B via / if / is a forward simulation 
from AtoB w.r.t. some invariants. Similarly for the other simulation relations. Appendix A gives 
formal definitions for all of these simulation relations. 

2.3 Execution Correspondence 

Simulation relations induce a correspondence between the executions of the concrete and the ab- 
stract automata. This correspondence is captured by the notion of i?-relation. If a' = uobiUib2U2 ■ ■ ■ 
is an execution of automaton B, then define trace{a',j, k) to be trace{bj ■ ■ ■ bk) if j < k, and to be 
A (the empty sequence) if j > A;. 

Definition 2 (i?-relation and Index Mappings) Let A and B be automata with the same ex- 
ternal actions and let R be a relation over states{A) x states{B). Furthermore, let a and a' be 
executions of A andB, respectively: 

a = soaiSia2S2 ■ ■ ■ 

a' = uobiUib2U2 ■ ■ ■ 

Say that a and a' are i?-related, written (a, a') G R, if there exists a total, nondecreasing mapping 
m : {0, 1, . . . , |a|} i— > {0, 1, . . . , |a'|} such that: 

1. m(0) = 0, 

2. {si,Um(i)) £ R for all i, < i < \a\, 

3. trace{a' ,m{i — 1) -|- l,m{i)) = trace{ai) for all i, < i < \a\, and 

4- for all j,0 < j < \a'\, there exists an i, < i < \a\, such that m{i) > j. 

The mapping m is referred to as an index mapping from a to a' with respect to R. Write {A, B) & R 
if for every execution a of A, there exists an execution a' of B such that {a, a') G R. 

Theorem 1 (Execution Correspondence Theorem) Let A and B be automata with the same 
external actions. Suppose A <x B via S, where X G {F, R, iB, H, iP}. Then {A, B) G S. 

Lemma 2 Let A and B he automata with the same external actions and let R he a relation over 
states{A) x states{B). If [a, a') G R, then trace{a) = trace{a'). 

Theorem 1 and Lemma 2 appear in [17] as Theorem 6.11 and Lemma 6.15, respectively. 
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2.4 Linecir-time Temporal Logic 



We use the fragment of linear-time temporal logic consisting of the □ (always) and O (eventually) 
operators over state assertions [47, 39]. In particular, we use the "infinitary" operators DO (in- 
finitely often) and OB (eventually always). We specify state assertions as a set of states, the state 
in question satisfying the assertion iff it belongs to the set. 

For example, if [/ is a set of states, then a \= OOU means "a contains infinitely many states from 
[/," and a \= OnU means "all but a finite number of states of a are from U." These operators can 
be combined with propositional connectives (->, A, V, ^) so that, for example, a \= DOU' BOU" 
means "if a contains infinitely many states from U' , then it also contains infinitely many states 
from U", and a \= On-i[/ means "all but a finite number of states of a are not from [/." 

Appendix B provides a formal definition of the syntax and semantics of the temporal logic that 
we use. 

3 Live Automata 

We first formalize the notions of live execution property and live trace property, that discussed in 
the introduction. 

Definition 3 (Live Execution Property) Let A be an automaton, and C execs'^ (A). Then, 
if is a live execution property for A if and only if for every finite execution a of A, there exists an 
infinite execution a' of A such that a < a! and a' & if. 

In other words, a live execution property is a set of infinite executions of A such that every finite 
execution of A can be extended to an infinite execution in the set. This requirement was proposed 
in [1] , where it is called machine closure. 

Note that we do not consider interaction with an environment in this paper. THis is why we 
use automata rather than I/O automata, i.e., we have external actions without an input/output 

distinction. This issue is treated in detail in [18], where a livcncss property is defined as a set of 
executions (finite or infinite) such that any finite execution can be extended to an execution in the 
set. Thus, an extension may be finite, unlike our approach. This is because requiring extension 
to an infinite execution may constrain the environment: an execution ending in a state with no 
enabled internal or output action will then require the environment to execute an action that is an 
output of the environment and an input of the automaton, so that the execution can be extended 
to an infinite one. We defer treating this issue to another occasion. 

Definition 4 (Live Trace Property) Let A he an automaton, and ip C traces{A). Then, ip is 
a live trace property for A if and only if there exists a live execution property ip for A such that 
tp = traces{(p). 

In [17, 18], the notion of live execution property was the basic liveness notion, and a live 
automaton was defined to be an automaton A together with a live execution property. This use of 
an arbitrary set of executions as a liveness property, subject only to the machine closure constraint 
resulted in a proof method in [17] which requires reasoning over entire executions. Since we wish 
to avoid this, we take as our basic liveness notion the complemented-pairs condition of Streett 
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automata, with the proviso that wc extend it to an infinite state-space and an infinite number of 
complemcntcd-pairs. In the next section, we show that this approach to specifying Hveness entails 
no loss of expressiveness, provided that we can use history variables. 

Let A be an automaton. We say that p is a complemented-pair^ over yl iff p is an ordered 
pair (Red, Green) where Red C states{A), Green C states{A). Given p = (Red, Green), we define 
the selectors p.R = Red and p.G = Green. Let a be an infinite execution of A. Then, wc write 
a 1= (Red, Green) iff a |= DORed DOGreen, i.e., if a contains infinitely many states in Red, then 
it also contains infinitely many states in Green. We also write a \= p in this case. Our goal is a 
method for refining liveness properties using reasoning over states and finite execution fragments 
only, in particular, avoiding reasoning over entire (infinite) executions. We therefore formulate a 
liveness condition based on states rather than executions. 

Definition 5 (Live Automaton with Complemented-pairs Liveness Condition) A live au- 
tomaton is a pair (A, L) where: 

1. A is an automaton, and 

2. L is a set of pairs {(Red^, Green^) | i G r/} where Red^ C states{A) and Green^ C states{A) 
for all i E r], and rj is some cardinal, which serves as an index set, 

and A, L satisfy the following constraint: 

• for every finite execution a of A, there exists an infinite execution a' of A such that 
a < a' and (Vp E L : a' \= p). 

{A, L) inherits all of the attributes of A, namely the states, start states, action signature, and tran- 
sition relation of A. The executions (execution fragments) of {A, L) are the executions (execution 
fragments) of A, respectively. We say that L is a complemented-pairs liveness condition over A. 
Often we use just "liveness condition" instead of "complemented-pairs liveness condition." 

The constraint in Definition 5 is the machine closure requirement, that every finite execution 
can be extended to a live execution. 

Definition 6 (Live Execution) Let {A, L) he a live automaton. An execution a of {A, L) is a 

live execution iff a is infinite and ^p E L : a \= p. 

We define lexecs{A, L) = {a \ a E execs'^ {A) and (Vp E L : a \= p)}. 

Our notion of liveness condition is essentially the acceptance condition for finite-state complemented- 
pairs automata on infinite strings [13], with the important difference that we generalize it to an 
arbitrary (possibly infinite) state space, and allow a possibly infinite set of pairs. Despite the pos- 
sibility that Red^ and Green^ are infinite sets of states, it is nevertheless very convenient to have 
an infinite number of complemented-pairs. Using the database example of the introduction, we can 
express the liveness property "every query submitted is eventually processed" as the infinite set 
of pairs {(x € wait,x wait) | x is a query}, and where wait is the set of all queries that have 
been submitted but not yet processed {x is removed from wait when it is processed). Being able 

^When it is clear from context, we just say "pair". 
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to allocate one pair for each query facilitates the very straightforward expression of this liveness 
property. Our extended example in Section 6 also uses an infinite number of pairs in this manner. 

The above discussion applies to any system in which there are an infinite number of distinguished 
operations, e.g., each operation has a unique identifier, as opposed to, for example mutual exclusion 
for a fixed finite number of processes,, where there are an infinite number of entries into the critical 
section by some process Pi, but these need not be "distinguished," since the single liveness property 
n{request{Pi) =^ <>critical{Pi)) is sufficient to account for all of these. The key point is that 
only a bounded number of outstanding requests must be dealt with (< the number of processes) , 
whereas in a system in which there are an infinite number of distinguished operations, an unbounded 
number of outstanding requests must be dealt with. We conjecture that the liveness property "every 
request is eventually satisfied" cannot even be stated using a finite number of complemented pairs. 

The safe preorder, live preorder [17] embody our notions of correct implementation with respect 
to safety, liveness, respectively. 

Definition 7 (Safe preorder, Live preorder) Let {A,L), {B,M) be live automata with the 

same external actions {ext{A) = ext{B)). We define: 

Safe preorder: {A,L) (B,M) iff traces (A) C traces{B) 

Live preorder: {A,L) {B,M) iff traces {lexecs {A, L)) C traces {lexecs{B,M)) 

From [34, 17], we have that simulation relations imply the safe preorder, i.e., if A <x B where 
X e {F,R,iB,H,iP}, then {A,L) {B,M). 

Returning to the database example of the introduction, if a is some live execution of the 
implementation A, then, along a, every continuously enabled action is eventually executed (action 
fairness) and every message sent is eventually received (message fairness). The trace /3 of a is then 
an externally visible live behavior oi A: f3 & traces (lexecs (A, L)). If A is a correct implementation, 
then we expect that the enforcement of action fairness and message fairness in A then guarantees 
the required liveness properties of the specification, namely that every query is eventually processed. 
Thus, the externally visible live behavior fi oi A must satisfy the required liveness properties of the 
specification, i.e., (5 G traces {lexecs {B,M)). This is exactly what the live preorder requires. 

Definition 8 (Semantic Closure of a Liveness Condition) Let {A, L) he a live automaton. 
The semantic closure L of L in A is given by L = {(R, G) j Va G lexecs{A, L) : a \= {R, G)}. 

L is the set of complemented-pairs over A which are "semantically entailed" by the complemented- 
pairs in L, with respect to the executions of A. In general, L — L is nonempty. Every pair in L — L 
represents a "derived" liveness property, since it is not directly specified by L, but nevertheless can 
be deduced from the pairs in L, when considering only the executions of A. 

Definition 9 (Derived Pair) Let {A,L) be a live automaton, and let p & L — L. Then p is a 
derived pair of {A, L). 

Proposition 3 L C L. 

Proof. Let p be any complemented-pair in L. Hence, by definition of lexecs {A, L), we have Vcc G 
lexecs{A, L) : a \= p. Hence p E L. □ 
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Proposition 4 lexecs{A,L) = lexecs{A,L). 

Proof. lexecs{A, L) C lexecs{A, L) follows immediately from Proposition 3 and the relevant defini- 
tions. Suppose a G lexecs{A, L). By Definition 8, E L : a \= p. Hence, a G lexecs{A, L). Hence 
lexecs{A, L) C lexecs{A, L). □ 

Prom Proposition 4, it follows that {A, L) is a live automaton. 



4 Refining Liveness Properties Across Levels of Abstraction: Liveness- 
preserving Simulation Relations 

The simulation relations given in Section 2.2 induce a relationship between the concrete automaton 
A and abstract automaton B whereby for every execution a oi A there exists a corresponding, 
in the sense of Definition 2, execution a' oi B. This correspondence between executions does not 
however take liveness into account. So, if we were dealing with live automata [A, L) and {B, M) in- 
stead of automata A and B, then it would be possible to have a G lexecs{A, L), a' lexecs{B, M), 
and {a, a') G S where S' is a simulation relation from A to B. So, /3 G traces {lexecs (A, L)) and 
/? ^ traces {lexecs {B, M)), where /? = trace{a), is possible. Hence establishing A <x B via S, where 
X G {F,R,iB,H,iP} does not allow one to conclude traces {lexecs {A, L)) C traces {lexecs {B, M)), 
as desired, whereas it does allow one to conclude traces{A) C traces{B), [17, Lemma 6.16]. For 
example, consider Pigures 1 and 2 which respectively give a specification and a "first level" refine- 
ment of the specification, for a toy database system. The database takes input requests of the form 
request(x), where x is a query, computes a response for x using a function val (which presumably 
also refers to the underlying database state, we do not model this to keep the example simple), 
and outputs a response {x,v) where v = val{x). This behavior is dictated by the specification 
in Pigure 1, where received queries are placed in the set requested, and queries responded to are 
placed in the set responded (this prevents multiple responses to the same query). The first-level 
refinement of the specification (Figure 2) is identical to the specification except that it can "lose" 
pending requests: the request(a;) nondeterministically chooses between adding x to requested, or 
doing nothing, as represented by Wskip in Pigure 2. Despite this fault, it is possible to establish a 
forward simulation F from DB-Im,p to DB-Spec, as follows. A state s of DB-Imp and a state u of 
DB-Spec are related by F if and only if s. requested C u. requested and s. responded = u. responded 
(where s.var denotes the value of variable var in state s). Now suppose we add the following live- 
ness condition to both DB-Imp and of DB-Spec: {{x £ requested, x G responded) | x is a query}. 
Thus, an operation x that has been requested must eventually be responded to, since x G requested 
is stable; once true, it is always true, and therefore it is true infinitely often. Now let a, a' be 
executions of DB-Imp, DB-Spec, respectively, which are related by F in the sense of Definition 2. 
Suppose some query xq is lost along a, and no other query is lost. Let a be live, i.e., if a query is 
placed into requested, and is not lost, then it will eventually be responded to. We now see that a' 
cannot be live, since xq G requested holds along an infinite suffix of a' , but xq G responded never 
holds along a'. Hence, establishing a forward simulation from DB-Imp to DB-Spec is not sufficient 
to establish live trace inclusion from DB-Imp to DB-Spec. 

This example demonstrates that the simulation relations of Section 2.2 do not imply live trace 
inclusion. The problem is that these simulation relations do not reference the liveness conditions 

of the concrete and abstract automata. To remedy this, we augment the simulation relations so 
that every pair q in the abstract liveness condition M is related to a pair p in the concrete liveness 
condition L. The idea is that the simulation relation relates occurrences of states in q.R, q.G in 
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Automaton DB-Spec 



Signature 



External: 

request(a;), where a; is a query 

response(a;, u), where x is a query and w is a value 



State 



requested, a set of received queries, initially empty 

responded, a set of computed responses to queries, initially empty 



Actions 



External request(i;) 
Pre: true 

Eff: requested <— requested U {x} 



External response(a;,j;) 

Pre: x 6 requested — responded Av = val {x) 

Eff: responded •<— responded U {x} 



Figure 1: Specification of a simple database system 



transitions of the abstract automaton {B,M) with occurrences of states in p.R, p.G in transitions 
of the concrete automaton {A,L). The relationship is defined so that the augmented simulation 
implies that, in "corresponding" executions a of (A, L), a' of (B, M), if a satisfies p, then a' must 
satisfy q. 

In more detail, an occurrence of a g.R state in an abstract (live) execution a' must be matched 
by at least one p.R state in the corresponding concrete (live) execution a, and an occurrence of a p.G 
state in a must be matched by at least one q.G state in a' . Thus, if a' \= DOg.R, then a \= DOp.R, 
and if a ^ OOp.G, then a' \= DO^.G. Assuming a is live, we get a \= OOp.R LJOp.G. This and 
the previous two implications yields a' \= DO^.R ^ DO^.G. Hence a' is live. Hence we can show 
that if an abstract execution a' and concrete execution a correspond (according to the simulation), 
and a is live, then a' is also live. The matching thus allows us to show that every live execution of 
{A,L) has a "corresponding" live execution in (B,M). Live trace inclusion follows immediately. 

Since the semantic closure L of L specifies the same set of live executions (Proposition 4) , as L 
does, we can relax the requirement p G L to p G L. Since L is in general a superset of L, this can 
be very helpful in refining the abstract liveness condition. In particular, it enables us to split the 
refinement task into two subtasks: refinement across abstraction levels (which we address in this 
section) and refinement within an abstraction level (which we address in the next section). 

Let (^4, L) be a live automaton, a be a finite execution fragment of A, and p £ L. We abuse 
notation and write a G p.R iff there exists a state s along a such that s G p.R. a G p.G is 
defined similarly. The above considerations lead to the following definitions of liveness-preserving 
simulation relations. 

Definition 10 (Liveness-preserving Forward Simulation w.r.t. Invariants) Let {A, L) and 

{B,M) be live automata with the same external actions. Let Ia, Ib be invariants of A, B respec- 
tively. Let f = {g, h) where g C states{A) x states{B) and h : M ^ L is a total mapping over M^. 

"That is, h{q) is defined for all q e M. 



11 



Automaton DB-Imp 



Signature 



External: 

request(a;), where a; is a query 

response(a;, u), where x is a query and w is a value 



State 



requested, a set of received queries, initially empty 

responded, a set of computed responses to queries, initially empty 



Actions 



External request(3;) 
Pre: true 

Eff: {requested *— requested U {x}) [] skip 



External response(a;,-!;) 

Pre: x 6 requested — responded Av = val{x) 

Eff: responded •<— responded U {x} 



Figure 2: First level refinement of the specification of a simple database system 



Then f is a liveness-preserving forward simulation from {A, L) to {B, M) with respect to I a and 



1. If s e staH{A), then g[s] D start{B) / 0. 

2. If s -—>-As' , s ^ Ia, and u G g[s] n Ib, then there exists a finite execution fragment a of 
B such that fstate{a) = u, lstate{a) € g[s'], and trace{a) = trace{a). Furthermore, for all 
qeM, 

(a) if a G q.R then s G p.R or s' G p.R, and 

(b) if s G p.G or s' G p.G then a G q.G, 

where p = h{q). 

3. Call a transition s -^a s' always-silent iff s G Ia and for every finite execution fragment a of 
B such that f state (a) G g[s] HIb, lstate{a) G g[s'], and trace{a) = trace{a), we have \a\ = 0, 
i.e., a consists of a single state. In other words, the transition s—^as' is matched only by 
the empty transition in B . Then, g is such that every live execution of {A, L) contains an 
infinite number of transitions that are not always-silent. 

Clause 1 is the usual condition of a forward simulation requiring that every start state of {A, L) 
be related to at least one start state of {B, M). 

Clause 2 is the condition of a forward simulation which requires that every transition s -^a s' 
of {A, L) be "simulated" by an execution fragment a of {B, M) which has the same trace. We also 
require that every complemented-pair g G M is matched to a complemented-pair p £ L hy the 
mapping h and that such corresponding pairs impose a constraint on the transition s -^a s' of 
{A, L) and the simulating execution fragment a. of {B, M), as follows. If a contains some q.R state, 
then at least one oi s,s' is & p.R state, and if at least one of s,s' is & p.G state, then a contains 



Ib iff: 



12 



some q.G state. This requirement thus enforces the matching discussed at the beginning of this 
section, from which hve trace inclusion follows. 

Clause 3 is needed to ensure that a live execution of {A, L) has at least one corresponding 
infinite execution in (B,M). This execution can then be shown, using clause 2, to be live (see 
Lemma 8 below). If s -^a s' is always-silent, then a must be an internal action. Thus, in practice, 
clause 3 holds, since executions with an (infinite) suffix consisting solely of internal actions are not 
usually considered to be live. Clause 3 can itself be expressed as a complemented-pair (which is 
added to L). Call an action a of ^ non-always-silent iff no transition arising from its execution is 
always-silent. Thus, every transition arising from the execution of a can be matched with respect to 
g by some nonempty execution fragment of B. It is also possible that the transition can be matched 
by the empty fragment, but what is important is that it is always possible to choose a nonempty 
fragment to match with. This means that we can always match a live execution a of {A, L) with 
some infinite execution of {B,M), by always matching the non-always-silent transitions in a with 
nonempty execution fragments of {B,M). 

By definition, any external action of A is non-always-silent. An internal action of A may or may 
not be non-always-silent. We introduce an auxiliary boolean variable nonalwayssilent that is set to 
true each time a non-always-silent action of A is executed, and is set to false infinitely often by a new 
internal action of A whose precondition is true and whose effect is nonalwayssilent := false (every 
execution of this new action can be simulated by the empty transition in B, since nonalwayssilent 
has no effect on any other state component of A, nor on the execution of other actions in A). Then 
the pair {true, nonalwayssilent) expresses that a non-always-silent action of A is executed infinitely 
often, which implies that each live execution of {A, L) contains an infinite number of non-always- 
silent transitions. The pair {true, nonalwayssilent) can then be refined at the next lower level of 
abstraction in exactly the same way as all the other pairs in L. See Section 6 for an example of 
this technique. 

It is clear from the definitions that if {g, h) is a liveness-preserving forward simulation from 
{A,L) to {B,M) w.r.t. invariants, then 5 is a forward simulation from A to B w.r.t. the same 
invariants. We write {A,L) {B,M) if there exists a liveness-preserving forward simulation 
from {A,L) to {B,M) w.r.t. invariants, and {A,L) <(f {B,M) via / if / is a liveness-preserving 
forward simulation from (^A, L) to {B, M) w.r.t. invariants. 

Definition 11 (Liveness-preserving Refinement Mapping w.r.t. Invariants) Let{A,L) and 
{B,M) he live automata with the same external actions. Let I a, Ib be invariants of A, B, respec- 
tively. Let T = {g,h) where g : states{A) 1-^ states{B) and h : M ^ L is a total mapping over M. 
Then r is a liveness-preserving refinement mapping from {A,L) to {B,M) with respect to I a and 
Ib iff: 

1. If s e start{A), then g{s) G start{B). 

2. If s -^A s' , s G I A, and g{s) G Ib, then there exists a finite execution fragment a of B such 
that f state {a) = g{s), lstate{a) = g{s'), and trace{a) = trace(a). Furthermore, for all q G M, 

(a) if a & q.R then s G p.R or s' G p.R, and 

(b) if s & p.G or s' G p.G then a G q.G, 

where p = h(q). 
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3. Call a transition s s' always-silent iff s ^ Ia and for every finite execution fragment a 
of B such that f state (a) = g{s), lstate{a) = g{s'), and trace{a) = trace{a), we have \a\ = 0, 
i.e., a consists of a single state. In other words, the transition s-^as' is matched only by 
the empty transition in B . Then, g is such that every live execution of {A, L) contains an 
infinite number of transitions that are not always-silent. 

We write A <£ji B if there exists a liveness-preserving refinement mapping from ^4 to i? w.r.t. 
invariants, and A <£ji B via r if r is a liveness-preserving refinement mapping from A to B w.r.t. 
invariants. It is clear from the definitions that a liveness-preserving refinement mapping is a special 
case of a liveness-preserving forward simulation. Furthermore, if (g, h) is a liveness-preserving 
refinement mapping from {A,L) to {B,M) w.r.t. some invariants, then g is a refinement mapping 
from AtoB w.r.t. the same invariants. 

Definition 12 (Liveness-preserving Backward Simulation w.r.t. Invariants) Let {A, L) and 

(B,M) be live automata with the same external actions. Let La, Ib be invariants of A, B respec- 
tively. Let b = {g,h) where g C states{A) x states{B) and h : M ^ L is a total mapping over M. 
Then b is a liveness-preserving backward simulation from {A, L) to {B, M) with respect to I a and 
Ib iff: 

1. If s e Ia, then g[s] n 7^ 0. 

2. If s e start{A), then g[s] HIb Q start{B). 

3. If s -^A s' , s ^ Ia, and u' G g[s'\ H Ib, then there exists a finite execution fragment a of B 
such that fstate{a) G g[s] H Ib, lstate{a) = u' , and trace{a) = trace{a). Furthermore, for all 

qe M, 

(a) if a & q.R then s G p.R or s' £ p.R, and 

(b) if s £ p.G or s' G p.G then a G q.G, 

where p = h{q). 

4- Call a transition s -^a s' sometimes-silent iff s E Ia and for some finite execution fragment 
a of B such that f state (a) G g[s] DIb, lstate{a) G g[s'], and trace{a) = trace{a), we have 
\a\ = 0, i.e., a consists of a single state. In other words, the transition s-^as' can be 
matched by the empty transition in B. Then, g is such that every live execution of iA,L) 
contains an infinite number of transitions that are not sometimes-silent. 

Clauses 1 and 2 are the usual conditions of a backward simulation requiring that a state in the 
invariant I a of (^4, L) is related to at least one state in the invariant Ib of {B, M), and that every 
start state of {A, L) is related only to start states of (S, M), ignoring states not in the invariant Ib- 
These clauses are needed due to the "backwards" nature of the bisimulation, since, from a state 
u' in the invariant Ib it is possible, when "going backwards" along a transition to reach a state u 
not in the invariant, i.e., u-^bu', u ^ Ib, and u' G Ib is possible. Also, a start state in {A,L) 
must always be matched by a start state in {B, M), since the matching state in {B, M) cannot be 
chosen initially: it is constrained by the succeeding transitions, i.e., it is "chosen" last of all, and 
so the result must be an initial state of B regardless of the choice. 

Clause 3 is the condition of a backward simulation which requires that every transition s -^a s' 
of iA,L) be "simulated" by an execution fragment a of {B,M), except that we also require that 
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every complemented-pair g € M is matched to a complcmcnted-pair p G L by the mapping h and 
that such corresponding pairs impose a constraint on the transition s -^a s' of {A, L) and the 
simulating execution fragment a of {B,M), as follows. If a contains some q.R state, then at least 
one of s,s' is a p.R state, and if at least one of s,s' is a p.G state, then a contains some q.G state. 
This requirement thus enforces the matching discussed at the beginning of this section, from which 
live trace inclusion follows. 

Clause 4 is needed to ensure that a live execution of (A, L) has at least one corresponding infinite 
execution in (B,M). This execution can then be shown, using clause 3, to be live (see Lemma 8 
below). If s-^As' is sometimes-silent, then a must be an internal action. Thus, in practice, 
clause 4 holds, since executions with an (infinite) suffix consisting solely of internal actions are not 
usually considered to be live. Clause 4 can itself be expressed as a complemented-pair (which is 
added to L), which can then be refined at the next lower level of abstraction. Call an action a 
of A non-sometimes-silent iff no transition arising from its execution is sometimes-silent. Thus, 
every transition arising from the execution of a must always be matched with respect to g by some 
nonempty execution fragment of B. 

We can now express the requirement that a non-sometimes-silent action of A is executed in- 
finitely often, as a complemented-pair, and refine this pair at the next lower level of abstraction. 
The details are similar to those discussed above for Clause 3 of Definition 10, and are omitted. 
Note the difference with forward simulation; there, we only had to ensure that it was infinitely of- 
ten possible to choose a nonempty execution fragment to match with. With backward simulations, 
we have to show that infinitely often, all the matching execution fragments are nonempty. 

It is clear from the definitions that if (g, h) is a liveness-preserving backward simulation from 
{A,L) to {B,M) w.r.t. some invariants, then 5 is a backward simulation from A to B w.r.t. the 
same invariants. We write A <£b B if there exists a liveness-preserving backward simulation from 
AtoB w.r.t. some invariants, and A <£b B via 6 if 6 is a liveness-preserving backward simulation 
from A to B w.r.t. some invariants. If the backward simulation g is image-finite, then we write 
A <iiB B, A <iiB B via b, respectively. 

Definition 13 (Liveness-preserving History Relation vi^.r.t. Invariants) Let {A,L) and 
(B,M) be live automata with the same external actions. Let I a, Ib be invariants of A, B, 
respectively. A history relation from A to B with respect to La and Ib is a relation hs over 
states (A) x states {B) that satisfies: 

1. hs is a liveness-preserving forward simulation from A to B w.r.t. La and Lb, and 

2. hs~^ is a refinement from B to A w.r.t. Lb and La- 

We write A <£b: B if there exists a liveness-preserving history relation from A to B w.r.t. some 
invariants, and A <£h B via hii his a liveness-preserving history relation from Ato B w.r.t. some 
invariants. 

Definition 14 (Liveness-preserving Prophecy Relation w.r.t. Invariants) Let {A,L) and 
{B, M) be live automata with the same external actions. Let La, Ib be invariants of A, B, re- 
spectively. A prophecy relation from A to B with respect to I a and Ib is a relation p over 
states (A) x states (B) that satisfies: 

1. p is a liveness-preserving backward simulation from A to B w.r.t. Ia and Ib, and 
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2. p ^ is a refinement from B to A w.r.t. Ib and Ia- 

We write A <£p B if there exists a liveness-preserving prophecy relation from A to B w.r.t. some 
invariants, and A <£p B viap Hp is a hveness-preserving prophecy relation from Ato B w.r.t. some 
invariants. If the liveness-preserving prophecy relation is image-finite, then we write A <np B, 
"^UP B via p, respectively. 

We use iF, £R, i£B, £H, UP to denote liveness-preserving forward simulation, liveness-preserving 
refinement mapping, image-finite liveness-preserving backward simulation, liveness-preserving his- 
tory relation, image-finite liveness-preserving prophecy relation, respectively. Thus, when we write 
X G {iF,£R,i£B,£H,i£P}, we mean that X is one of these relations. 

Liveness-preserving simulation relations induce a correspondence between the live executions 
of the concrete and the abstract automata. This correspondence is captured by the notion of R^- 
relation. We remind the reader of the definition trace(a' , j, k) = traceihj ■ ■ ■ bk) if j < k, and = A 
(the empty sequence) if j > fc. 

Definition 15 (i?^-relation and Live Index Mappings) Let {A, L) and {B, M) he live automata 

with the same external actions. Let R^ = {R,H) where R is a relation over states (A) x states (B) 
and H : M L is a total mapping over M. Furthermore, let a and a' be executions of {A, L) and 
{B,M), respectively: 

a = soaiSia2S2 ■ ■ ■ 

a' = uobiUib2U2 ■ • • 

Say that a and a' are i?^-related, written (a, a') G R^, if there exists a total, nondecreasing mapping 
m : {0, 1, . . . , \a\} ^ {0,1, ... , \a'\} such that: 

1. m(0) = 0, 

2. {si,Ujn{i)) € R for all i, < i < \a\, 

3. trace{a',m{i — 1) -|- l,m{i)) = trace{ai) for all i, < i < \a\, 

4- for all j,0 < j < \a'\, there exists an i, < i < \a\, such that m{i) > j, and 
5. for all complemented-pairs q E M and all i, < i < \a\ : 

(a) if G m{i — 1) . . . m{i) : Uj G q.R) then G p.R or Si E p.R, and 

(b) if Si-i G p.G or si G p.G then i^j G m{i — 1) . . . m{i) : Uj G q.G), 

where p = H{q). 

The mapping m is referred to as a live index mapping from a to a' with respect to R^ . Write 
{{A,L),{B,M)) G R^ if for every live execution a of {A,L), there exists a live execution a' of 
{B,M) such that {a, a') G R^. 

Note that {a, a') G R^ does not require a, a' to be live executions. By Definitions 2 and 15, it is 

clear that, if R^ = {R, H), then {a, a') G R^ implies {a, a') G R. The following lemma establishes a 
correspondence between the prefixes of a live execution of the concrete automaton and an infinite 
family of finite executions of the abstract automaton. 
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Lemma 5 Let {A, L) and {B, M) be live automata with the same external actions, and such that 
{A, L) <£p {B, M) via f for some f = (g, h). Let a he an arbitrary live execution of [A^ L). Then 
there exists a collection {a[,mi)o<i of finite executions of {B,M) and mappings such that: 

1. rui is a live index mapping from a\i to a'^ with respect to f , for all i>Q, and 

-2. ca'i-i < oi[ and mi-i = mi t{0, . . . , z — 1} for all i> Q, and 

3. oi[_i < a[ for infinitely many i > 0. 

Proof. Let a = so«iSia2S2 • • • and let /a, Ib be invariants of A, B, respectively, such that / is 
a liveness-preserving forward simulation from {A,L) to {B,M) with respect to I a and Ib- We 
construct and rui by induction on i. 

Since sq € start{A), we have {sq,vq) € g and vq G start{B) for some state vq, by Definition 10, 
clause 1. Let a'^ = vq and let mg be the mapping that maps to 0. Then, mo is a live index 
mapping from q|o to with respect to / (in particular, clause 5 of Definition 15 holds vacuously, 
since |a|ol = 0). 

Now inductively assume that mj-i (for z > 0) is a live index mapping from a\i-i to a^_^ with 
respect to /. Let uq = lstate{a[_i) . Then, by clause 4 of Definition 15 and the fact that mj_i 
is nondecrcasing, we have mj_i(i — 1) = |Q!'j_i| and (sj_i,Mo) G g. Since Sj, and uq are 

reachable, by definition, they satisfy their respective invariants. Hence, by Definition 10, clause 2, 

there exists a finite execution fragment uq-^bUi-'^b ••• --^BUn of B such that Un G 9[si], 
trace{bi ■ ■ ■ 6„) = trace{ai), and for all complemented-pairs q G M: 

1. if (3j G 1 . . . n : Uj q.R) then s,j_i G p.R or Sj G p.R, and 

2. if Si-i G p.G or Si G p.G then (3j G 1 . . . n : -u j G q-G), 

where p = h{q). Now define = a'^_i'~~{uo — ^^i —^B ■ ■ ■ —^b Un), and define to be the 
mapping such that mi{j) = mj_i(j) for all j, < j < i — 1, and mi{i) = \a^\. We argue that rui is 
a live index mapping from a\i to a'- with respect to /, i.e., that all clauses of Definition 15 hold. 
Clause 1 holds since mi{0) = mj_i(0) by definition, and mj_i(0) = by the inductive hypothesis. 
Clause 2 holds by the inductive hypothesis and G g[si]. Clause 3 holds by the inductive hypoth- 
esis and trace{bi ■ ■ - bn) = trace{ai). Clause 4 holds since mj(| a|j |) = mi{i) = \a'^\, by definition. 
Finally, clause 5 holds by the inductive hypothesis and the conditions for all complemented-pairs 

q £ M just established above w.r.t. Sj_i Si and uq — ""i —^b • ■ ■ —^b Un- Having estab- 
lished that rui is a live index mapping from a\i to a[ with respect to /, we conclude that clause 1 
of the lemma holds. 

Clause 2 of the lemma holds by construction of and rui, since and rui are obtained by 
extending q;^_j and mj_i, respectively. 

By Definition 10, clause 3, for infinitely many i > 0, we can select the execution fragment 

Uq —^b ui —^B ■ • • —^B Un that matches -^a s-i so that n > 0. Hence, for infinitely many 
i > 0, we have a^_^ < a^. Thus, clause 3 of the lemma holds. □ 

Definition 16 (Induced Digraph) Let {A,L) and {B,M) be live automata with the same ex- 
ternal actions and assume A <ub B via h = {g, h) with respect to invariants I a o,nd Ib- For any 
execution a = soaiSia2S2 • • • of A, let the digraph induced by a, h, Ib, L, and M be the directed 
graph G given as follows: 
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1. The nodes of G are the ordered pairs {u,i) such that <i < \a\, and u G g[si\ DIb, and 

2. there is an edge from {u,i) to {u',i') iff i' = i + 1 and there exists a finite execution frag- 
ment a' of B such that fstate{a') = u, lstate{a') = u' , trace{a') = trace{ai+i), and for all 
complemented-pairs q & M: 

(a) if a' € q.R then Si G p.R or Sj+i G p.R, and 

(b) if Si G p.G or Sj+i G p.G then a' G q.G, 

where p = h{q). 

Lemma 6 Let (A, L) and {B, M) be live automata with the same external actions and assume 
A <UB B via b with respect to invariants I a and Ib- Let a be any execution of A. Then the 
digraph G induced by a, b, Ib, L, and M satisfies: 

1. For each i, ^ < i <\oi\, there is at least one node in G of the form {u,i). 

2. The roots of G are exactly the nodes of the form (w, 0). 

3. G has a finite number of roots. 

4- Each node in G has finite outdegree. 

5. Each node of G is reachable from some root of G. 

Proof. Let b = {g,h). Then g is an image-finite backward simulation from A to B. We deal with 
each clause in turn. 

1. Each state Sj of a is reachable, and so belongs to Ia- Hence g[si] n Is 7^ by Clause 1 of 
Definition 12. Hence by Definition 16, clause 1, there exist nodes of G of the form {u,i). 

2. Every node (it, 0) is a root of G (i.e., it has no incoming edges). We now show that any 
node (n, z) with i > cannot be a root. Now u G g[si] D Ib by Definition 16, clause 1. 
Also, Si-i G Ia and -^a Si by assumption, hence by Definition 12, clause 3, there 
exists a finite execution fragment a' of B such that fstate{a') G g[si-i] fl Ib, lstate{a') = u, 
trace{a') = trace{ai), and, for all q G M, 

(a) if a' E q.R then G p.R or Sj G p.R, and 

(b) if Si-i G p.G or Sj G p.G then a' G q.G, 

where p = h{q). Hence, by Definition 16, clause 2, there exists an edge in G from {fstate{a'),i— 
1) to {u,i). 

3. Since g is image-finite, the set g[so] fl Ib is finite. By Definition 16, clause 1, all nodes of G 

of the form (n, 0) must satisfy u G g[so] H Ib- Hence, there are a finite number of such nodes. 
By clause 2 of the lemma (which has already been established), these nodes are exactly the 
roots of G. Hence, the number of roots is finite. 

4. Let {u, i) be an arbitrary node of G. By Definition 16, clause 2, from any node of the form 
{u,i), all outgoing edges are to nodes of the form {u',i + 1). Since g is image-finite, the set 
^[si+i] n Ib is finite. By Definition 16, clause 1, all nodes of G of the form {u,i + 1) must 
satisfy u G (7[sj_|-i] HIb- Hence, there are a finite number of such nodes. Hence, the outdegree 
of any node of G of the form (u, i) is finite. Since (u, i) was chosen arbitrarily, the result 
follows. 
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5. We establish this by induction on the second component i of the nodes {u, i) of G. For the 
base case, i = and nodes (u, 0) arc reachable by definition since they are roots. Assume the 
induction hypothesis that all nodes of the form (u, i) are reachable from some root of G, and 
consider an arbitrary node of the form {u,i + 1). 

Now u G nis by Definition 16, clause 1. Also, Sj G I a and Si Si+i by assumption, 

hence by Definition 12, clause 3, there exists a finite execution fragment a' of B such that 
fstate{a') G g[si] CMb, lstate{a') = u, trace{a') = trace{ai^i), and, for all q G M, 

(a) if a' E q.R then Sj G p.R or Sj+i G p.R, and 

(b) if Si G p.G or Sj+i G p.G then a' G g.G, 

where p = h{q). Hence, by Definition 16, clause 2, there exists an edge in G from {fstate{a'),i) 
to {u,i + 1). By the induction hypothesis, {/state {a'), i) is reachable. Hence, so is {u,i + 1). 

Since all the clauses are established, Lemma 6 holds. □ 

Lemma 7 Let (A, L) and {B, M) be live automata with the same external actions, and such that 
{A,L) <UB {B,M) via b for some b = {g,h). Let a be an arbitrary live execution of {A,L). Then 
there exists a collection {a'^,mi)o<i of finite executions of {B,M) and mappings such that: 

1. rrii is a live index mapping from a\i to a[ with respect to b, for all i >0, and 

2. a[_^ < a[ and nii-i = nii \{Q, . . . , i — 1} for all i > 0, and 
3- a'i^i < Oi[ for infinitely many i > 0. 

Proof. Let a = soaiSia2S2 • • • and let Ia, Lb be invariants of A, B, respectively, such that 6 is a 
image-finite liveness-preserving backward simulation from (A, L) to {B, M) with respect to I a and 
Ib- Let G be the digraph induced by a, 6, Ib, L and M. Since a is infinite (all live executions are 
infinite, by Definition 5), G is infinite. Hence, by clauses 3 and 4 of Lemma 6, and Konig's lemma, 
G contains an infinite path. Fix p = (uq, 0)(ui, 1), . . . to be any such path. By Definition 16, 
clause 1, G g[si\ fl Ib for all i > 0. We now construct a.[ and by induction on i, with such 
that lstate{a'j) = Ui. 

Now So £ start{A) since a is an execution of A. Also, by Definition 16, uq G g[sQ\ fl Ib- Hence, 
by clause 2 of Definition 12, uq G start{B). Let ctg = uq and let mo be the mapping that maps 
to 0. Then, mo is a live index mapping from a\o to ckq with respect to b (in particular, clause 5 of 
Definition 15 holds vacuously, since |q!|o| = 0), and lstate{a'Q) = uq. 

Now indTictivcly assume that mj_i (for i > 0) is a live index mapping from to a'^_i with 

respect to b, and that lstate(a'-_i) = Mj-i. By construction of path p, there is an edge in G from 
{ui-i,i — 1) to {ui, i). Hence, by Definition 16, there exists a finite execution fragment a" such that 
fstate{a") = Ui-i, lstate(a") = Ui, trace{a") = trace(ai), and, for all complemented-pairs q G M: 

1. if a" G q.R then Sj_i G p.R or Si G p.R, and 

2. if Sj_i G p.G or Si G p.G then a" G q.G, 

where p = h{q). Now define a'- = a'^_^^a" , and define mi to be the mapping such that mi{j) = 
mi-i{j) for all j, < j < i — 1, and mj(i) = \a'^\. We argue that is a live index mapping from 
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a\i to a'j^ with respect to b, i.e., that all clauses of Definition 15 hold, and that lstate{a'-) = Ui. 
Clause 1 holds since mj(0) = mj_i(0) by definition, and mj_i(0) = by the inductive hypothesis. 
Clause 2 holds by the inductive hypothesis, lstate{a") = Ui, and Ui € g[si] (which we established 
above). Clause 3 holds by the inductive hypothesis and trace {a") = trace (ai). Clause 4 holds since 
"lid a|i I) =mi{i) = \a^\, by definition. Finally, clause 5 holds by the inductive hypothesis and the 
conditions for all complemented-pairs g G M established above w.r.t. Sj_i -^ASi and a". Having 
established that rrii is a live index mapping from a\i to a[ with respect to /, we conclude that 
clause 1 of the lemma holds. Also, lstate{a'j) = Mate {a") = Ui, as required for the induction step 
to be valid. 

Clause 2 of the lemma holds by construction of and m^, since and are obtained by 
extending a'j^_i and rrii-i, respectively. 

By Definition 12, clause 4, for infinitely many i > 0, the execution fragment a" which matches 
Si-i — Si must have length \a"\ > 1. Hence, for infinitely many i > 0, we have a'j^_i < ct^. Thus, 
clause 3 of the lemma holds. □ 

Our next lemma shows that, if infinite concrete and abstract executions correspond in the sense 
of (a, a') G R^, and the concrete execution is live, then so is the abstract execution. 

Lemma 8 Let {A, L) and {B, M) be live automata with the same external actions. Let = 
{R,H) where R is a relation over states (A) x states (B) and H : M ^ L is a total mapping over 
M. Let a, a' be arbitrary infinite executions of{A,L), {B,M) respectively, //(a, a') G R^, then 
a G lexecs{A, L) implies a' G lexecs{B,M). 

Proof. We assume the antecedents of the lemma and establish a' ^ lexecs{B,M) implies a 
lexecs{A, L). Let: 

a = soaiSia2S2 ■ ■ ■ 

a' = UQbiUib2U2 ■ ■ ■ 

Since (a, a') G R^, there exists a live index mapping m : {0, 1, . . . , |a|} i-^ {0, 1, . . . , \a'\} satisfying 
the conditions in Definition 15. Suppose a' ^ lexecs{B,M). Then, by Definition 6, there exists a 
complemented-pair q e M such that a' \= nOq.R A On-ig.G. Let p = H{q). We prove: 

a\=nOp.RAOa^p.G. (*) 
Since a' \= OOq.R, there exist an infinite number of pairs of states (ttm(i-i)) ^^m(i)) along a' that 
contain a q'.R-state between them (inclusive, i.e., the g.R-state could be tim(i-i) or ^^(i)). By 
clauses 2 and 3 of Definition 15, for each such pair there corresponds a pair of states (sj-i, Sj) along 
a such that (sj_i, M„j(j_i)) G R and (si, 'u„j(j-)) G R. Also, by clause 5a of Definition 15, Sj-i G p.R 
or Si G p.R. Since this holds for an infinite number of values of the index i, we conclude 

a ^ aOp.R. (a) 
Since a' \= OB-iq.G, there exists a state Ug along a' such that > g : ue ^ q.G. Now assume 
that a \= OOp.G. Since m is nondecreasing and cofinal in {0, 1, . . . , |a'|} (clause 4, Definition 15), 
there exists an along a such that Sj_i G p.G and m{i — 1) > g- By clauses 2 and 3 of 

Definition 15, isi-i,Um,(i-i)) G R and (sj, Uj^^i^) G R. Also, by clause 5b of Definition 15, at least one 
of . . . , is a state. Since m{i — l)>g, this contradicts > g ■ U£ ^ q.G 

above. Hence the assumption a \= UOp.G must be false, and so: 

a \= On^p.G. ^ (b) 

From (a) and (b), we conclude (*). From (*), we have a ^ p. Now p £ L, since H : M ^ L. 
Hence, a ^ lexecs{A, L) by Definition 6. Hence, by Proposition 4, a lexecs{A, L). □ 

We can now establish a correspondence theorem for live executions. Our theorem states that, if 
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a livcncss-prcscrving simulation relation S is established from a concrete automaton to an abstract 
automaton, then for every live execution a of the concrete automaton, there exists a corresponding 
(in the sense of (a, a') G S^) live execution a' of the abstract automaton. Our proof uses Lemmas 5 
and 7 to establish the existence of an infinite family of finite executions corresponding to prefixes 
of a. We then construct a' from this infinite family using the "diagonalization" technique of [17]. 
Finally, we invoke Lemma 8 to show that a' is live, given that a is live. 

Theorem 9 (Live Execution Correspondence Theorem) Let {A,L) and {B,M) be live au- 
tomata with the same external actions. Suppose {A, L) <x {B, M) via S\ where X e {lF,m,iiB, 
iH,ieP}. Then {{A, L) , {B , M)) G S^. 

Proof. We proceed by cases on X. 

Case 1: X = IF. So is a liveness-preserving forward simulation / = {g,h), and {A,L) <£f 
{B,M) via /. Let a = SoaiSia2S2 ... be an arbitrary live execution of {A,L), and let {a'^,mi)o<i 
be a collection of finite executions of (B, M) and mappings as given by Lemma 5. By definition 
of {{A,L),{B,M)) € /, we must show that there exists a live execution a' of {B,M) such that 
(a, a') G /. 

By Definition 6, a is infinite. Let m be the unique mapping over the natural numbers defined 
by m{i) = mi{i), for all i>0. Let a' be the limit of under the prefix ordering, that is, a' is the 

unique execution of {B,M) defined by = (^i for all i > 0, with the restriction that for any 

index j of a', there exists an i such that a'\j < a-. By Lemma 5, clause 3, a' is infinite. 

We now show that m is a live index mapping from a to a' with respect to /. The proof that m is 
nondecreasing and total and satisfies clauses 1-4 of Definition 15 proceeds in exactly the same way 
that the proof of the corresponding assertions does in the proof of the Execution Correspondence 
Theorem in [17]. We repeat the details for sake of completeness. 

Suppose m is not nondecreasing. Then there exists an i such that m{i) < m{i — 1). However, 
m{i) = mi{i) and m{i — 1) = mi-i{i — 1) = mj(i — 1), so this contradicts the fact that mi is an 
index mapping and is therefore nondecreasing. Likewise, we can see that the range of m is within 
{0,...,|a'|}. 

Clause 1 of Definition 15 holds since mo is an index mapping and therefore satisfies mo(0) = 0. 
Hence m(0) = mo(0) = 0. Assume clauses 2 or 3 do not hold. Then, there must exist an i for 
which one of the clauses is invalidated. However, this contradicts the fact that, for all i, rrii is an 
index mapping from a\i to a'^ with respect to /. Now assume that clause 4 does not hold. Hence, 
there is an index j in a' such that m{i) < j for all i. By definition of a', there exists an i such that 
oi\j < a[. Thus |a'| > j. Now Lemma 5 gives us mi{i) = \a'^\. Hence m{i) > j, since m{i) = mi{i). 
This contradicts m{i) < j. 

Now assume that m violates clause 5 of Definition 15. Then, there exists a pair q € M and an 
i > for which clause 5 is invalidated. However, this contradicts the fact that, for all i > 0, mj 
is a live index mapping from a\i to with respect to / (Lemma 5, clause 1). Hence m satisfies 
clause 5 of Definition 15. Since m satisfies all clauses of Definition 15, m is a live index mapping 
from a to a' with respect to /, and so (a, a') G /. Since a G lexecs{A, L), (a, a') G /, and a, a' 
are both infinite, we can apply Lemma 8 to conclude a' G lexecs(B, M), i.e., a' is a live execution 
of {B,M), which establishes the theorem in this case. 

Case 2: X = IR. So is a liveness-prcscrving refinement mapping r = [g, h) and [A, L) 
[B, M) via r. Since a liveness-preserving refinement mapping is a liveness-preserving forward 
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simulation, the result follows from Case 1. 

Case ?>: X = i£B. So is an image-finite liveness-preserving backward simulation b = {g,h), 
and {A,L) <i(,B {B,M) via b. The argument is identical to that of Case 1, except that we invoke 
Lemma 7 instead of Lemma 5. 

Case A: X = iH. So is a liveness-preserving history relation hs and {A,L) <^h iB,M) via 
hs. Prom Definition 13, hs is a liveness-preserving forward simulation from A to B. Hence, the 
argument of Case 1 applies. 

Case 5: X = UP. So is an image-finite liveness-preserving prophecy relation p = {g,h), and 
{A, L) <iip (B, M) via p. From Definition 14, p is an image-finite liveness-preserving backward 
simulation from A to B. Hence, the argument of Case 3 applies. 

Since all cases of X have been dealt with, the theorem is established. □ 

We now establish our main result: liveness-preserving simulation relations imply the live pre- 
order. 

Theorem 10 (Liveness) Let {A, L) and {B, M) be live automata with the same external actions. 
Suppose {A,L) <x {B,M), where X G {eF,eR,ieB,m,i£P}. Then {A,L) Q {B,M). 

Proof. Prom {A,L) <x iB,M), we have {A,L) <x {B,M) via for some = {g,h). We 
establish traces {lexecs {A, L)) C traces {lexecs {B, M)), which, by Definition 7, proves the theorem. 
Let P be an arbitrary trace in traces (lexecs (A, L)). By definition, /? = trace{a) for some live 
execution a G lexecs(A, L). By the Live Execution Correspondence Theorem (9), there exists a 
live execution a' € lexecs{B, M) such that (a, a') G S^. Since (a, a') G S^, we have {a, a') G g 
by Definitions 2 and 15. Hence, by Lemma 2, trace{a) = trace{a'). Hence /? = trace{a'), and so 
P G traces (lexecs (B, M)), since a' G lexecs(B, M). Since /? was chosen arbitrarily, we conclude 
traces (lexecs (A, L)) C traces (lexecs (B,M)), as desired. □ 

5 Refining Liveness Properties Within the Same Level of Abstrac- 
tion 

The previous section showed how to refine an abstract liveness condition M to a concrete liveness 
condition L: every pair q E M is mapped into some pair p in the semantic closure L of L, and 
then a liveness-preserving simulation relation that relates the R and G sets of p, q appropriately is 
devised. We assume that the liveness properties L, M are directly specified, and so the pairs in M 
and in L are easy to identify.^ However, pairs in L — L are not directly specified, but only given 
implicitly by A, L, and Definition 8. Thus, the question arises, given a pair q E M that is mapped 
to some pair p, how do we establish p E LI We do so as follows. 

Given such a pair p, we refine it into a finite "lattice" of pairs that are already known to be 
in L. Let P be a finite subset of L, and let -< be an irreflexive partial order over P^ . If r G P, 

define succ(r) = {wEP\r<wf\ \/w' : r<w'<w^r = w'}, where r < w = r ~< w or 
r = w. Thus, succ(r) is the set of all "immediate successors" of r in (P, ^). We now impose two 

^For example, if we were attempting to mechanize our method, we would assume that M, L are recursive sets. 
^Following convention, we shall refer to this ordered set simply as P when no confusion arises. 
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technical conditions on P: (1) for every pair r, the G set of r must be a subset of the union of 
the R sets of all the immediate successors of r, i.e., r.G C IJuies«cc(r) ^-R) ^iiid (2) P has a single 
^-minimum element bottom(P), and a single -(-maximum element top(P), and bottom(P).R = p.R 
and top{P).G = p.G. 

Now let a be an arbitrary live execution of {A,L). Then, a \= DOr.R ^ DOr.G and a \= 
OOw.R =^ nOw.G, for all w G SMCc(r). Since succ{r) is finite and r.G C U«;Gsucc(r) follows 
that, if r.G holds infinitely often in a, then w.R holds infinitely often in a, for some w G succ{r). 
Hence, by "chaining" the above implications, we get a \= DOr.R =^ '-'^ U«iGs«cc{r) Thus, 
{r.R, (J^gg^^^^y,-) w.G) G L by Definition 8. Thus, the -< ordering provides a way of relating 
the complemented-pairs of P so that the complemented-pairs property (infinitely often R im- 
plies infinitely often G) can be generalized to encompass a pair and its immediate successor 
pairs. By starting with the -<-minimum pair bottom{P), and applying the above argument induc- 
tively (using -< as the underlying ordering), we can establish the complemented-pairs property for 
i^ottom{P).R, top{P).G), i.e., a \= aObottom{P).R ^ □Otop(P).G, and so {bottom{P).R, top{P)^) G 
L. Since we require bottom{P).R = p.R and top{P).G = p.G, we obtain the desired result that p E L. 

Definition 17 (Complemented-pairs Lattice) Let {A,L) be a live automaton. Then {P,~<) is 
a complemented-pairs lattice over L iff"^ 

1. P is a finite subset of L, 

2. -< is an irreflexive partial order over P, 

3. P contains an element top{P) which satisfies \fr e P : r :< top{P), and an element bottom{P) 
which satisfies ^r E P : bottom{P) :< r, and 

l^reP- {top{P)} : r.G C U^e«„cc(r) "^-R- 

The elements top{P) and hottom,{P) are necessarily unique, since ^ is a partial order. Let lattices{L) 
denote the set of all complemented-pairs lattices over L. 

Lemma 11 Let {A, L) be a live automaton, (P, -<) G lattices{L), _L = bottom{P), and T = top{P). 
Then (±.R,T.G> G L. 

Proof. Let a be an arbitrary live execution of {A,L). We show a \= DOJ-.R ^ nOT.G. By 
Definition 8, this establishes the lemma. 

We assume a \= nO±.R and establish a \= DOT.G. First, we establish: 

If r G P, r 7^ T, and a \= DOr.R, then a \= OOw.R for some w G succ{r). (*) 
Proof of (*): Assume the antecedent of (*). Since a is live and r G L, we have a \= DOr.R =^ 
□Or.G by Definition 8. Hence a \= DOr.G. By Definition 17, r.G C UjoGsucc(r) ^-R- Hence 
a \= ^'^[jyj^succir)''^-^- Since P is finite, succ{r) is finite. It follows that a \= BOw.R for some 
w G succ{r). (End of proof of (*).) 

We now construct a sequence ri, r2, . . . , r^, . . . of pairs in P such that Vi > 1 : a |= nOr^.R. We 
let ri = _L, noting that a \= DOJ-.R by assumption. We derive r^+i by applying (*) to r^. It follows 

'^Note that we use the term "lattice" in an informal sense, since our complemented-pairs lattices do not satisfy 
the mathematical definition of a lattice. 
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by induction on the length of the derived sequence that a [= DOrj+i.R {r\ = _L supphes the base 
case). Now suppose T is not in ri, r2, . . . Then (*) can be apphed indefinitely. Since rj+i G succ{ri), 
it follows that rj -< rj+i for all j G Hence rj rj+i for all j G Thus ri, r2, ... is an infinite 
sequence of pairwise different complemented-pairs in P. But this is impossible, since P is finite. 
Hence the assumption that T is not in ri, r2, . . . is false. It follows that ri, r2, . . . is a finite sequence 
of pairwise different complemented-pairs, with T as its last member. Hence a \= DOT.R. Since a 
is live and T eL, a\= DOT.R =^ DOT.G. Hence a \= nOT.G, as desired. □ 

We remark that when constructing a lattice to refine a complemented-pair, we can use require- 
ment 4 of Definition 17 (r.G C U«)esucc(r) '^■^) ^ ^ constraint that suggests how to order the 
complemented-pairs of the lattice. Also, while Lemma 11 presents one method of establishing the 
membership of complemented-pairs in L, our overall methodology is not restricted to this particular 
method. Any appropriate deductive technique that suffices can be used, for example that of [40], 
which is based on linear temporal logic. This provides a way of using deductive methods gener- 
ally, and those based on temporal logic in particular, within a framework which accommodates the 
refinement of liveness properties across multiple levels of abstraction. 

6 Example — The Eventually Serializable Data Service 

The eventually-serializable data service (ESDS) of [14, 26] is a replicated, distributed data service 
that trades off immediate consistency for improved efficiency. A shared data object is replicated, 
and the response to an operation at a particular replica may be out of date, i.e., not reflecting the 
effects of other operations that have not yet been received by that replica. Thus, operations may 
be reordered after the response is issued. Replicas communicate amongst each other the operations 
they receive, so that eventually every operation "stabilizes," i.e., its ordering is fixed with respect 
to all other operations. Clients may require an operation to be strict, i.e., stable at the time of 
response, and so it cannot be reordered after the response is issued. Clients may also specify, in 
an operation x, a set x.prev of other operations that should precede x (client-specified constraints, 
CSC). We let O be the (countable) set of all operations on the data object, and V be the set of 
all possible results of operations in O. TZ is the set of all replicas, and client{x) is the client issuing 
operation x. We use x,y to index over operations, c to index over clients, and r,r',i to index over 
replicas. Each operation x has a unique identifier x.id. X is the set of identifiers of operations in 
O. 

In Appendix C, we give the I/O automata code (in "precondition-effect" style) from [14]. I/O 
automata [33] add an input/output distinction to the external actions, i.e, all external actions 
of an automaton are either input actions (which must furthermore be enabled in all states), or 
output actions. This is needed to define a parallel composition operator || with good composi- 
tional properties. Figure 7 gives the environment of the ESDS system: a set of users, or clients, 
which output requests request(x) to perform operations x, and input responses response(x, v) to 
the requests, with returned value v. Figure 8 presents the specification ESDS-I. As a high-level 
specification, ESDS-I is a single automaton, and therefore it does not address issues of concurrency 
and distribution. The only concern is to specify the set of correct traces, which are by definition 
the traces of ESDS-I. ESDS-I inputs requests request(x), and outputs responses response(a:;, u) to 
the requests, with returned value v. Once request(x) has been received, it is "entered" into the 
current partial order po, via internal action enter(x, new-po), which updates the value of po to that 
given by new-po. This new value must include all operations in x.prev, and all operations that 
have stabilized, as preceding x. Note that span{R) = {x \ xRy V yRx}, where i? is a binary rela- 
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tion. At any time, it is permissible to impose new ordering constraints, which is done by internal 
action add_constraints(nei(;-po). The stabilize(x) internal action checks that x is totally ordered 
with respect to all other operations (Vy G ops, y -<po x y x y), and that all operations that 
precede x have already stabilized {opsl^^^x ^ stabilized). In this case, x itself can be stabilized. 
The calculate(,T, v) internal action computes a return value v for the operation x. If x is strict, then 
calculate(a;, f ) checks (in its precondition) that x has stabilized. The valset{x, ops, ~<po) function 
returns the set of all values for x which are consistent with the set ops of all operations that have 
been entered, and the partial order -^po defined by po. The actual value returned is then chosen 
nondeterministically from this set. 

As an intermediate step, we refine ESDS-I to a second level specification ESDS-II. This refine- 
ment consists only of changing some of the transitions. The state space and the signature remain 
the same. Figure 9 presents these changes, as changes to the "precondition-effect" definitions of 
some of the actions in the action list. The main difference with ESDS-I is that the precondition to 
stabilize an operation x is relaxed: now, all operations that precede x are not required to be stable 
themselves, but are only required to be totally ordered with respect to all other entered operations 
{~<po totally orders ops\^^^x)- This intermediate version ESDS-II is useful, as it is easier to con- 
struct a simulation from the implementation to ESDS-II, and another simulation from ESDS-II 
to ESDS-I, than it is to construct a simulation from the implementation directly to ESDS-I. 

The implementation consists of front-ends, replicas, and channels. Each client c has a front-end 

Frontend{c), see Figure 10, which inputs requests request(x), and relays them onto one or more 
of the replicas Replica{r), via output action sender (( "request" , x)). Frontend{c) receives responses 
from the replicas via input action receiver.c(( "response" , x, f)), and relays the response onto the 
client via output action response(a;, w). While the frontend can receive several replies for x from 
various replicas, it only relays one of these onto the client. A replica r (Figure 11) receives requests 
to perform operation x via input action receivec- (( "request" , x)). It queues received operations into 
a set pending^, of pending operations. A pending operation x can be "performed" by the internal 
action doJtr(x, /) if all operations in x.prev have been performed. In this case, x is assigned a "la- 
bel" I larger than the labels of all operations known to be done at replica r. This label determines 
the values that can be returned for x, using the valset function. Once x has been processed by 
do_itr(a;, I), a value v for x can be returned by the output action sendrc(( "response" , x, v)). v is non- 
deterministically chosen from among the set returned by valset {x, doner[r], -<icr), which computes 
all values for x that are consistent with the set done^lr] of operations done at replica r, and the 
partial order -<ic^ on operations that is determined by the labels assigned to each operation. In ad- 
dition, replicas "gossip" amongst each other, by means of the actions sender' (("gossip" , R, D, L, S)) 
and receiver'r(("gossip", i?, D, L, 5)). The purpose of gossiping is to bring each other up to date 
on the operations that they have executed. All communication between the front-ends and the 
replicas is by means of reliable asynchronous channels. Figure 12 shows a channel from process i 
to process j with messages drawn from some set M. 

We will use ESDS-Alg to refer to the parallel composition of all replicas, front-ends, and 
channels, with all send and receive actions hidden^. Since the users must be taken into account, 

the first-level specification, second-level specification, and implementation arc the I/O automata 
ESDS-I II Users, ESDS-II \\ Users, and ESDS-Alg \\ Users, respectively. We refer the reader to [14] 
for a complete description of the ESDS system. 

*I/0 automata composed in parallel synchronize on actions with the same name, and otherwise execute indepen- 
dently. An action is hidden by removing it from the set of output actions and adding it to the set of internal actions. 
We refer the reader to [14, section 3] for formal definitions of parallel composition and hiding. 
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G is a relation between states in ESDS-II \\ Users and ESDS-I \\ Users, such that {s,u) G G if and 
only if s G states {ESDS-II \\ Users), u G states {ESDS-I \\ Users), and: 

• u.wait = s.wait 

• u.rept = s.rept 

• u.ops = s.ops 

• u.po = s.po 

• u. stabilized D s. stabilized 



Figure 3: Forward Simulation from ESDS-II \\ Users to ESDS-I \\ Users 

The liveness condition used in (the conference version of) [14] is that every request should 
eventually receive a response, and every operation should stabilize. We express this as the following 
complemented-pairs liveness condition M-I for the specification ESDS-I \\ Users:^ 

• {{x G 'wait,x ^ wait) \ x G O}, i.e., every request eventually receives a response. 

• {{x G wait,x G stabilized) \ x G O}, i.e., every operation eventually stabilizes. 

Because the number of submitted operations x in general grows without bound with time, a count- 
ably infinite number of pairs is needed to express this liveness condition in the natural manner 
illustrated above. Note that we use predicates to denote sets of states. 

6.1 Refinement from ESDS-I \\ Users to ESDS-II \\ Users 

The top-level specification ESDS-I \\ Users and second-level specification ESDS-II \\ Users have the 
same state-space, they only differ in some actions, as shown in Figure 9. Hence, we let the liveness 
condition M-II of ESDS-II \\ Users consist of the same complemented-pairs as those in M-I, and 
we map each pair of M-I into the same pair of M-II. 

In [14], it is shown that the relation G given in Figure 3 is a forward simulation relation 
from ESDS-II \\ Users to ESDS-I \\ Users. We show that G is also a liveness-preserving forward 
simulation. For the pair (,t G wait,x wait) it is clear that G satisfies clause 2 of Definition 10, 
since G only relates states that agree on the value of wait. For the pair {x G wait, x G stabilized), we 
see from Figure 3 that if s G states {ESDS-II \\ Users) and u G states{ESDS-I \\ Users) are related by 
G, and s satisfies x G stabilized, then u also satisfies x G stabilized, since s. stabilized C u. stabilized. 
Since s and u agree on the value of wait, we conclude that G satisfies clause 2 of Definition 10, for 
this pair too. 

By inspection, we verify that, in every live execution of ESDS-II, there is an infinite number 
of executions of non-stabilize actions. Now according to the definition of G in Figure 3, every 
action in ESDS-II is simulated by the same action in ESDS-I, except for the stabilize action; a 
single stabilize(a;) action in ESDS-II can be simulated by a possibly empty sequence of stabilize 

^Throughout this section, our notation is consistent with [14]. 
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actions in ESDS-I. Hence, any transition generated by executing any action other than stabilize is 
not always-silent, by clause 3 of Definition 10. Since every live execution of ESDS-II contains an 
infinite number of these transitions, clause 3 of Definition 10 is satisfied. 

Since each pair of M-I is mapped into a pair of M-II itself, rather than the semantic closure 
M-II of M-II, we are done (i.e., there is no need to construct complemented-pairs lattices for these 
pairs) . 

Since Definition 10 is now satisfied, we have estabhshed {ESDS-II \\ Users, M-II) <£p {ESDS-I \\ 
Users, M-I). Hence, applying Theorem 10, we conclude {ESDS-II \\ Users, M-II) {ESDS-I \\ 
Users, M-I). 

6.2 Refinement from ESDS-II \\ Users to ESDS-Alg \\ Users 

Let L be the liveness condition of ESDS-Alg || Users. Since ESDS-Alg \\ Users is an implementation, 
we take L to be the following: every action that is continuously enabled from some point onwards 
is eventually executed (fair scheduling), and every message that is sent is eventually received (fair 
polling of channels). These are reasonable liveness properties to expect of an implementation. 

We map the pair {x G wait,x ^ wait) of M-II into the pair {x G waitc,x ^ waitc), where 
c = client{x) is the client that requests operation x. We map the pair (x G wait,x G stabilized) of 
M-II into the pair {x G waitc, x G flj stablei[i]). 

The proof obligations are then to exhibit a liveness-preserving forward simulation for this choice 
of pair-mapping, and to show that the pairs {x G waitc, x ^ waitc) and {x G waitc, ^ ^ Oi stablei[i]) 
are members of L, since they are not members of L. 

6.2.1 Establishing a Liveness-preserving Forward Simulation 

In [14], it is shown that the relation F given in Figure 4 is a forward simulation relation from 
ESDS-Alg II Users to ESDS-II \\ Users. We establish that F is also a liveness-preserving forward 
simulation. We first 

By Definition 23, F already satisfies clause 1 of Definition 10. We argue that F also satisfies 
clauses 2 and 3. Let SpReq = (x G wait,x ^ wait), ImpReq = (x G waitc, x waitc), SpStab = 
(x G wait,x G stabilized), ImpStab = (x G waitc, x £ f}j^ stablei[i]) . Let B = ESDS-II \\ Users, 
and A = ESDS-Alg \\ Users. Let s,u range over the states of ESDS-Alg \\ Users, ESDS-II \\ Users 
respectively. We use the notation s.v to denote the value of state variable v in state s, and likewise 
for u.v. 

Establishing clause 2 of Definition 10 for the pairs SpReq = (x G wait,x wait) G M-I and 
ImpReq = (x G waitc, x ^ waitc). F relates states s and u only if u.wait = [j^s.waitc- Hence 
X G u.wait iff X G s.waitc, where c = client{x). Thus is a SpReq.R state iff s is a ImpReq.R state, 
and u is a SpReq. G state iff s is a ImpReq. G state. 

Let s-^As' and consider all possibilities for a. If a is one of send (along any channel), 
receive (from any channel), or do_it,, (for any replica r), then a docs not change waitc (for any 
client c), and the actions of ESDS-II \\ Users that simulate a do not change wait. Hence if 

uq — ^^1 —^B U2 —^B • • • —^BUn is the simulating execution fragment of ESDS-II \\ Users, cor- 
responding to s -^A s' for the aforementioned cases of a, then we immediately conclude that (1) all 
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F is a relation between states in ESDS-Alg || Users and ESDS-II \\ Users, i.e., F C 
states {ESDS-Alg\\ Users) x states{ESDS-II\\ Users), such that {s,u) G F if and only if: 

• u. requested = s. requested 

• u. responded = s. responded 

• u.wait = [j^s.waitc 

• u.rept = Up s.rept^ U s. potential -rept^ 

• u.ops = s.ops = Uy, s.doner[r] 

• u.po C s.po 

• u. stabilized = f^^ s.stabler[r] 

where s. potential -rept^ = {{x,v) \ ("response", u) G \J.^. s. channel rc A s.waitc} is the set of re- 
sponses en route to Frontend{c), and u.po is the partial order induced by the various operation 
constraints in the implementation. See [14] for details. 



Figure 4: Forward simulation from ESDS-Alg \\ Users to ESDS-II \\ Users 

Ui,i G . . . n have the same value of wait, and (2) s and s' have the same value of IJ^ waitc- Together 
with UQ.wait = [J^ s.waitc, this allows us to conclude {3i E . . .n : Ui E SpReq.R) iff s G ImpReq.R 
or s' G ImpReq.R, and s G ImpReq.G or s' G ImpReq.G iff {3i E 0...n : Ui G SpReq.G). Thus 
clause 2 of Definition 10 is satisfied in this case. 

If a is request(a;), this is simulated by the same action in ESDS-II \\ Users, request(x) adds x to 
waitc in ESDS-Alg\\ Users, and adds x to wait in ESDS-II \\ Users. Hence, using similar reasoning 
as above, we easily verify that clause 2 of Definition 10 is satisfied in this case. The argument for 
a = response(x, v) is similar. This concludes our argument that clause 2 of Definition 10 holds for 
the pairs SpReq and ImpReq. 

Establishing clause 2 of Definition 10 for the pairs SpStab = (x G wait,x G stabilized) G 
M-I and ImpStab = (x G waitc, x € f^^ stablei[i]) . F relates states s and u only if u.wait = 
Up s.waitc and u.stabilized = f]^ s.stablei[i] (definition of F in [14], and Figure 4). Hence x G u.wait 
iff' X G s.waitc, where c = client[x), and x G u.stabilized iff x G {^^s.stablei\i\. Thus u G SpStab.R 
iff s G ImpStab .R, and u G SpStab. G iff s G ImpStab. G. 

Let s — s' and let uq — '-^b "Ui — U2 —^b ■ ■ ■ —^b Un be the execution fragment of ESDS-II \ \ 
Users that simulates s -—>-a s'. Given the previous remarks, we conclude immediately that clause 2 
of Definition 10 is satisfied when ui, . . . , Un-i are not present, i.e., the simulating fragment consists 
of either a single state or a single transition. 

The only case where uq b Ui b U2 — ^ s • • • — ^ b Un consists of more than one transition is 
when a = receive,.,./ (m) . In this case, the actions hi, . . . ,bn are add_constraints(s'.po), stabilize(xi), . . . , 
stabilize(xfc), where {xi,...,Xk] = {^^s' .stable i[i\ (see [14], Section 8). Now {^^s. stable i[i] C 

s' .stable i[i\ by inspection of the receive^r' ('^) action in Figure 11. Also, uq. stabilized = s.stablei[i\, 
and Un- stabilized = f]^ s' .stablei[i] = {xi, . . . ,Xk}, by definition of F and xi, . . . ,Xk. 
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Now receive^r' does not affect waitc, and acld_constraints(s'.po), stabilize(xi), . . . , stabilize(xfc) 
do not affect wait. Hence, (3i G . . . n : lij G SpStab.R) iff s € ImpStab.R or s' € ImpStab.R. Afso, 
suppose s € ImpStab.G or s' € ImpStab.G, i.e., x € s.sto6lei[^] or a; G s'.staWei[^]- Hence 
a; € f]^ s' .stablei[i] since P|j s.sto6fei[i] C s'.sta6Zei[i]- Since Un-stabilized = f]^ s' .stable we 
have X G Un- stabilized. Hence Un € SpStab.G. Hence (3z G 0. . .n : -Uj G SpStab.G). 

We have thus established clause 2 of Definition 10 for the pairs SpStab and ImpStab. 

Establishing clause 3 of Definition 10. From Figure 11, it is clear that the action sender' ("^) 
(for some m) is continuously enabled, and hence executed infinitely often in any live execution of 
ESDS-Alg\\ Users. Hence, the action recewerr' {m) is also executed infinitely often. Now, according 
to the definition of F (see [14], Section 8), receive^r' ('^) is simulated by the sequence of actions 
add_constraints(s'.po), stabilize(xi), stabilize(xfc), where {xi, . . . ,Xk} = f]^ s' .stable i[i], and s' is 
the state of ESDS-Alg \\ Users resulting from the execution of receive,.r/(T?T,). Thus, receive^^' (m) 
is always matched by at least one action, namely add_constraints(s'.j9o). Hence, any transition 
generated by executing receive^r' (m) is not always-silent, by clause 3 of Definition 10. Since every 
live execution of ESDS-Alg \\ Users contains an infinite number of these transitions, clause 3 of 
Definition 10 is satisfied. 

6.2.2 Establishing Membership in L 

Establishing {x G waitc, x ^ wait^) G L. We use a complemented-pairs lattice over L, together 
with Lemma 11, to establish {x G waitc, x waitc) € L. Recall that L is the complemcntcd- 
pairs liveness condition for the implementation ESDS-Alg \\ Users. At the implementation level, 
the natural liveness hypothesis is that each continuously enabled action is eventually executed, and 
each message in transit eventually arrives. We use this hypothesis to justify the pairs in L (which are 
also in L, by definition). Figure 5 shows the complemented-pairs lattice that we use. c = client{x) 
is the client that invoked operation x. We display the portion of the lattice corresponding to a 

single replica r. The : indicate where isomorphic copies corresponding to the other replicas occur 
(the number of replicas is finite). Let L consist of all the pairs in Figure 5. It is straightforward to 
verify that Figure 5 satisfies all the conditions of Definition 17. We justify the complemented-pairs 
in Figure 5 as follows: 

1. (x G waitc^r .< "request", x >G channelcr)- 

sender is continuously enabled and eventually happens, for at least one replica r. 

2. (< "request", X >G channelcr, x G pending,, fl rcvdr). 

Liveness of channelcr, and the definition of action receivccr- in Figure 11. 

3. (x G pending^ H rcvdr, x € pending^ fl doner[r]}. 

If x.prev C doner[r] holds continuously, then cither do-it^ is continuously enabled and even- 
tually happens (making x G doner[r] true), or do.it^ is disabled because x G doner[r] becomes 
true due to a gossip message. Establishing x.prev C doner[r] essentially requires a "sublat- 
tice" for each x' G x.prev. This sublattice is a "chain" consisting of three pairs, with the 
ordering (a) -< (b) -< (c): 

(a) (x G pending^ fl rcvdr, x' G pending^/ fl rcvd,') is the bottom element. It is justified since 
each client includes in x.prev only operations that have already been requested. Thus 
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{{x,v) e rept^,x ^ waitc) 



(< "response" , X, t; >e channelrc, {x,v) € rept^} 



{x € pending^, fl doner[r] A x. strict, 
< "response" , a;, t; >G channelrc 
> 



{x G pending J. fl doner[r] A -'X. strict, 
< "response" , a;, t; >G channelrc 

> 



(x e pending r n rcvdr, x € pending r n doner[r]) 



(< "request", X >e channelcr,x S pendingr n rcvdr) 




{x e waitc, ^r ■< "request", x >e channelcr) 



Figure 5: Complemented-pairs lattice that establishes (x G waitc,x ^ waitc) & L {c= client{x)). 

x' G x.prev is eventually received by some replica r', at which point x' G pending riCwcvdj.' 
holds. 

(b) (x' G pendinQr' Ci rcvdr', x' S pendingr' ^ c?oner/[r']) is the middle element. It is justified 
"inductively," i.e., it can be expanded into a sublattice in exactly the same way as 
{x G pendingr ^ rcvdr, x € pendingr ^ doner[r]). This "nested" expansion is guaranteed 
to terminate however, since x.prev is finite, for all x. 

(c) {x' G doner'[r'],x' G doner[r]} is the top element. It is justified since r' eventually sends 
a gossip message to r. 

By applying Lemma 11 to this sublattice, we conclude (x G pending rCi rcvdr, x' € doner[r]) G 
L. Now doner[r] increases monotonically, x' G doner[r] is stable — once true, it remains true. 
Hence, from the aforementioned pair for each x' G x.prev, we conclude that x.prev C doner[r] 
eventually holds, and remains true subsequently, as required. 

Note that the condition I > labelr{y.id) does not need to be verified as eventually holding, 
since it merely expresses a constraint on the value of the "action parameter" I, i.e., the 
only instances of clo_itr(x,/) which are enabled are those having values of / that satisfy I > 
labelr{y-id). That is, / is properly regarded as part of the "name" of the action doJ\tr{x,l). 

4. {x G pendingr ^ doner[r] A x. strict, < "response", x, v >G channelrc) ■ 

This is justified by the following sublattice, where the ordering relation is (a) -< (b) -< (c) -< 
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(d) ^ (e). a; G pending j., x. strict, arc implicit conjuncts of all the predicates in the sublattice, 
except the Green predicate of pair (e), and are omitted for clarity. 

(a) {x G ndoner[r],x G r\r'doner'[r']}. Justified since r sends gossip messages to every other 
replica r'. 

(b) {x G rir-i doner' [r'], X G stabler[r]}. Justified since each r' sends gossip messages to r. 

(c) {x G stabler[r],x G Cir' stabler' [r']). Justified since r sends gossip messages to every other 
replica r'. 

(d) {x G rir'stabler'[r'],x G Cir' stabler[r']) . Justified since each r' sends gossip messages to 
r. 

(e) {x G Or' stabler[r'], < "response" , ar, w >G channelrc)- Justified since x G pending j., 
x G doner[r], and x G r\r' stabler[r'] all hold continuously, since doner[r] and stabler[r'] 
grow monotonically. Hence sendrc{< "response", >) is continuously enabled, and so 
is eventually executed. 

5. {x G pending^, fl doner[r] A ^x. strict, < "response" , x, v >G channelrc) ■ 
sendrc{< "response" , X, w >) is continuously enabled and eventually happens. 

6. (< "response" , X, u >G channelrc-, {x,v) G rept^. 

Livcncss of channelrc-, and the definition of action receive,.c in Figure 10. 

7. ((Xju) G rept^,x waitc). 

response(x, v) is continuously enabled and eventually happens. 

Establishing (x G waitc, x £ flj •^^^^^^^[i]) G L. We use the complemented-pairs lattice over L 
given in Figure 6 together with Lemma 11. The bottom three complemented-pairs in Figure 6 also 
occur in Figure 5, and have therefore already been justified. We justify the remaining pairs as 
follows. 

1. (x G doner[r],x G Hi donei[i]}. Justified since r sends gossip messages to every other replica. 

2. (x G Plj donei[i],x G stabler[r]}. Justified since each i sends gossip messages to r. 

3. (x G stabler[r],x G f^^ stablei[i]) . Justified since r sends gossip messages to every other 
replica. 

Since Definition 10 is now satisfied, we have established {ESDS-Alg\\ Users, L) <£p (ESDS-II \\ 
Users, M-II). Hence, applying Theorem 10, we conclude (ESDS-Alg \\ Users, L) (ESDS-II \\ 
Users, M-II). Together with {ESDS-II \\ Users, M-II) {ESDS-I\\ Users, M-I) established above, 
we have {ESDS-Alg \\ Users, L) Q {ESDS-I\\ Users, M-I), as desired. 

We have illustrated three levels of abstraction, and two liveness-preserving forward simulations, 
between the top and middle, and middle and bottom levels. It is straightforward to continue this 
process. For example, an actual implementation would not simply route a request to any replica, but 
would select the replica according to certain criteria, for example load balancing/performance [44], 
or distance from the client [48]. Thus, the front-ends and replicas would be refined to incorporate a 
load-balancing/anycast/replica (or mirror) location "service" which, given a request from a client 
c, assigns some replica r to service that request. We then map the complemented-pair (x G 
waitc^r :< "request", x >G channelcr) into a pair at the next lower level which expresses the 
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{x e stabler[r],x € stablei[i]} 




{x e Plj donei[i],x e stabler[r]) 



{x € doner[r],x € donej[i]) 



{x e pending J. n rcvdr, x G pending^ Ci doner[r]} 



(< "request", a; >G channelcr,x G pending^ n rcvdr) 




{x e waitc^r :< "request", x >G channelcr) 



Figure 6: Complemented-pairs lattice that establishes (x G waitcX G sto6/ej[^]) G (c = 
cZ«ent(a;)). 

liveness of the service: the service eventually assigns some replica r to every request x. This pair 
could then be justified by constructing a lattice whose elements are the specified or derived liveness 
properties of the service. 

7 Discussion 

7.1 Alternative Choices for Specifying Liveness Properties 

We have used the complemented-pairs acceptance condition to specify liveness properties. There 

arc other acceptance conditions for finite aiitomata over infinite strings that we could have chosen: 
Buchi, gcncralizcd-Buchi, Rabin, and Mullcr. Wc briefly discuss each in turn. 

A Buchi condition is a single set Green of states, and the computation must contain an infinite 
number of states from Green. This can be expressed as a single complemented pair (irae. Green), 
and so is subsumed by complemented-pairs. A gcncralizcd-Buchi condition is a set {Greenj | i G ry} 
of sets of states, and for each Greeny, the computation should contain an infinite number of states 
from Greenj. This can be expressed as the set of complemented-pairs {{true, Greenj) | i G ry} and 
so is also subsumed by complemented-pairs. 

The Rabin condition is a set {{true, Greeny) \ i E rj} of pairs, however the acceptance condition 
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is different. A computation a is accepted iff for some pair (Redj, Greerij), a does not contain an 
infinite number of states in Redj, and a does contain an infinite number of states in Greerij. This 
condition is a "disjunctive" one, it constrains a computation only with respect to any one of the 
pairs, not all of them at once. Since, in writing specifications, conjunction is far more useful than 
disjunction, i.e., we typically list some properties all of which must be satisfied, we feel that this 
condition would not be useful in practice. 

The Muller condition is a set {Greerij | z G ??} of sets of states, and, the set of states that occur 
infinitely often along the computation should be exactly one of the Green,. This condition is not 
very suitable for an infinite-state model, since it is possible (and indeed, often the case) that an 
infinite computation does not contain any particular state that recurs infinitely often, since the 
model usually contains unbounded data, such as integers, reals, sequences, or sets. Thus, the set 
of states each of which occurs infinitely often along the computation, is usually empty. 

Finally, we consider the "temporal leads-to" property. Roughly, p leads-to q means that, when- 
ever p holds, then q subsequently holds. In our framework, leads-to properties can be expressed 
and verified by using history variables. Let flagp be a boolean history variable that is initially 
false, is set whenever p A ^q holds, and reset whenever q holds. Then, the complemented-pair 
{flagp, q) expresses "p leads-to q." Since flagp is not used to affect control fiow, it does not need to 
be "implemented." Thus, the issue of atomically detecting the values of p and q at run time and 
updating flagp, does not arise. 

7.2 Application to Fault-tolerance 

Our method can be applied to the verification of fault tolerance properties. We consider situations 
in which the occurrence of a fault can cause the system to enter a "bad" state, i.e., one that 
is unreachable under normal execution [5]. Let good denote the set of states that are reachable 
under normal system execution from a start state, and let fault denote the set of states that result 
immediately after a fault occurs, i.e., the post-states of faults (the faults can occur in any state, 
good or bad). If follows that, under normal execution (no faults) only good states are reachable 
from good states. 

We are interested in "nonmasking" fault-tolerance properties of the type: once faults stop 
occurring, the system will eventually recover to a good state (and therefore remain forever after 
in good states, since only good states are reachable from good states in the absence of faults). 
Expressed in temporal logic, this is {OU-ifault DOgood). This is logically equivalent to 

no {fault V good). We can express this as the complemented pair {true, fault V good). 

Hence, the liveness condition {true, faultV good) defines the set of "live" executions to be either 
(1) those along which an infinite number of faults occur (in which case we have no obligation to 
recover to a good state) or (2) those along which an infinite number of good states occur. In the 
latter case, we may also assume that faults stop occuring, since the negation of this is covered by 
case (1). Since only good states are reachable from good states, it follows that there is some suffix 
consisting entirely of good states, and so the system has recovered. 

Thus, "live" executions are those in which the system exhibits the desired fault-tolerance prop- 
erty. The trace of such an execution is then an "external fault-tolerant behavior." 

We can now refine such nonmasking fault-tolerance properties, i.e., to establish that the exter- 
nal fault-tolerant behaviors of an implementation are included in those of the specification. Our 
framework thus can take the place of theories that are specialized to dealing with nonmasking 
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fault-tolerance, e.g., [12], which we have shown is just a particular kind of liveness property. 



7.3 Mechanization Of Our Method 

Our method imposes the following proof obligations: 

1. Devise an appropriate liveness-preserving simulation and check that it satsifies all of the 
conditions of its definition (one of Definitions 10-14). 

2. For each derived pair, devise a complemented-pairs lattice and check that it satisfies the 
conditions of Definition 17. 

These conditions can be formalized in a first-order assertion language with interpreted symbols. 

We refer the reader to [16, 19] for details. The conditions can be verified using theorem provers 
such as PVS [46]. For lack of space, wc omit an extended discussion of these issues, which can 
be found, for example, in [19]. That paper presents normed simulations, where the existence of a 
finite execution fragment at the abstract level that matches a concrete transition is replaced by the 
existence of either a single matching transition, or an internal transition that decreases a supplied 
norm (a function over a well-founded domain). It should be possible to extend the ideas in this 
paper to normed simulations. For example, if the concrete transition contains a Red state, then 
we require that, by the time that either the matching abstract transition has been generated, or 
the norm function has decreased to minimum, that a corresponding Red state has appeared at the 
abstract level. We leave the details to another occasion. 

8 Expressive Completeness of Complemented-pairs Liveness Con- 
ditions 

We now investigate the expressiveness of complemented-pairs: what are the live execution properties 
which can be expressed by complemented-pairs conditions? First, we make this notion precise. 

Definition 18 Let A be an automaton and let (p be a live execution property for A. Then we say 
that a liveness condition L expresses ip if and only if {A, L) is a live automaton and lexecs{A, L) = ip. 

The use of (complemented-pairs) liveness conditions to specify liveness means that the liveness 
of an execution depends only on the set of states which occur in that execution, and not on their 
ordering. This is necessary, to satisfy the machine closure condition, since ordering is a safety 
property: once an ordering is violated along a finite execution, no extension can then satisfy the 
ordering. 

In Section 8.1, we show that, under some assumptions that are natural for infinite-state sys- 
tems, that the generalized Buchi condition is expressively complete, i.e., they can express any live 
execution property. Since complemented pairs subsumes generalized Buchi, the result then carries 
over to our framework. 

In Section 8.2, we show that complemented pairs are expressively complete if history variables 
can be used. 
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8.1 Relative Expressive Completeness of Complemented-pairs Liveness Condi- 
tions 

In infinite-state systems, it is often the case that the occurrence of "significant" events is perma- 
nently recorded by changes to the state. For instance, in the eventually-seriahzable data service 
of Section 6, the execution of every operation on the data results in a permanent record of that 
operation's unique identifier. Any database system which maintains logs is also an example of this. 
So is a real-time system in which clocks maintain the time, if we consider the passage of time to be a 
significant event. This large class of systems justifies the assumption that a particular state cannot 
repeat infinitely often along a live execution, since we expect that significant events (e.g., operation 
execution, transaction commit, time passage) occur infinitely often along a live execution. Thus, 
we assume the following condition in this section: 

Assumption 1 (No infinite repetition) Let {A,L) he a live automaton, and a = SQaiSi . . . he 
a live execution of (A, L) . Then, there is no state s such that s = Si for an infinite number of 
values for the index i. That is, no state occurs infinitely often along a. 

Since a generalized-Buchi condition depends only on the set of states which occur in that 
execution, we take it as reasonable that if one execution contains "more" states than another, and 
the latter execution is live, then the former execution should also be live. In this section, we restrict 
attention to liveness properties which satisfy this condition, which we call robust properties. Our 
notion of one execution containing "more" states than another is captured by a relation < between 
executions. 

Definition 19 (<) Let a = sqUiSi . . . and 7 be infinite executions of automaton A. Then 7 < a 
iff there exists a suffix 7' = uobiui ... 0/7 and a mapping m : {0, 1, . . .} 1-^ {0, 1, . . .} such that 

1. > : Sjn(i) = Ui, and 

2. Vz > : ^^"^{1) is a finite set. 

Thus, 7 <l a iff 7 has some suffix 7' which can be put into a correspondence with a as follows. 
If a state s occurs some finite (> 0) number of times in 7', then state s also occurs some finite 
number of times in a. If s occurs infinitely often in 7', then s also occurs infinitely often in a. 
Note that Assiunption 1 does not rule this out, since it applies only to live executions. < is clearly 
refiexive and transitive, and so is a preorder. We formalize the condition discussed above as the 
class of robust live execution properties. 

Definition 20 (Robust Live Execution Property) Let if be a live execution property for au- 
tomaton A. Then, ip is robust for A if and only if: 

for all 7, a G execs^{A), if j < a and 7 £ then a G y?. 

Our robustness condition corresponds more closely to using a generalized-Buchi acceptance con- 
dition than a complemented-pairs acceptance condition (see Section 7.1 above). Since complemented- 
pairs subsume generalized-Buchi, this is still within our framework, and also allows for a simpler 
technical development. The definition of live trace properties corresponding to robust live execution 
properties is straightforward. 
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Definition 21 (Robust Live Trace Property) Let A be an automaton, and ip C traces (A). 
Then, ip is a robust live trace property for A if and only if there exists a robust live execution 
property if for A such that ^ = traces {ip) . 

We now show that an execution in ip can be distinguished from an execution outside ip by means 
of a simple Buchi acceptance condition. For an execution a, define states (a) = {s\ s occurs along a} 

Proposition 12 Let A be an automaton, and let if be an arbitrary robust live execution property 
for A. Let 7, a G execs^{A) be such that 7 £ and a ^ ip. Then there exists a set Ga^-y C states{A) 
such that 7 \= DOGa^-y Q^c^ \= '^"'^0,7- 

Proof. Since 7 is an infinite execution, we have by Assumption 1 that states {'j) is an infinite set. 
Now suppose that states {■^f) — states (a) is a finite set. Then, by Assumption 1, there exists a suffix 7' 
of 7 which contains no state in states (7) — states (a). Hence states (7') C states (a). By Assumption 1 
each state along 7' repeats only a finite number of times. Hence we have 7' < a by Definition 19. 
Hence 7 < a, again by Definition 19. Thus by Definition 20, a G (p, contrary to assumption. We 
conclude that states{'j) — states{a) is an infinite set. Thus 7 |= □0(states(7) — states{a)). Also, 
a \= □-i(states(7) — states{a)), by definition. So, letting G^^-y = states{'y) — states{a) establishes 
the proposition. □ 

We next show that an execution outside ip can be distinguished from every execution inside ip 
by means of a simple Buchi acceptance condition. 

Proposition 13 Let A be a,n automaton, and let ip be an arbitrary robust live execution property 
for A. Let a € execs^{A) be such that a ^ p. Then there exists a set Gq, C states (A) such that 
a \= n-iGa and G p : ^ \= DOGq. 

Proof. Let 7 be an arbitrary execution in p, and let Ga,-y be the set given by Proposition 12 for a, 
7. Then 7 j= nOG^^^ and a \= □-iGa,^. Let G^ = [jj^t^ G^^^. Then, V7 G 99 : 7 |= DOG^, since 
Ga,7 ^ Gq. Also, a \= n-iGQ. since a \= D-iGa^-y for every Ga^-y, 7 £ □ 

We now present the relative completeness result: every execution outside ip can be distinguished 
from every execution inside ip by means of a generalized-Buchi acceptance condition. 

Theorem 14 (Relative Expressive Completeness of Generalized-Buchi) Let A be an au- 
tomaton, and let ip be an arbitrary robust live execution property for A. Then there exists a 
generalized-Buchi condition L = {Gj | z € 77} over A such that <^ = {7 | Vz G : 7 |= DOGj}. 

Proof. If ip = execs'^ (A) then letting L = {true} establishes the theorem. Hence we assume that 
ip is a, proper subset of execs'^ (A) for the rest of the proof. Let a be an arbitrary execution in 

execs^{A) — p, and let G^ be as given in Proposition 13 for a. Let L = {G^ | ct € execs'^{A) — ip}. 
Define lexecs{A,L) = {7 | Va G execs'^ (A) — (/? : 7 |= UOGa}- We show that p = lexecs{A,L). The 
proof is by double-containment. 

lexecs{A, L) C ip: Choose arbitrarily a ^ p. So a G execs^{A) — p. Hence a \= □-■Ga by 
Proposition 13, and so o; ^ UOG^. Thus a ^ lexecs{A, L) by definition of lexecs{A, L). Taking the 
contrapositive yields a G lexecs{A,L) implies a E ip, i.e., lexecs{A, L) C ip. 

p C lexecs{A, L): Choose arbitrarily j £ p and a G execs^{A) — p. Hence 7 |= nOGQ, by 
Proposition 13. Hence Va G execs^{A) — p : ^ \= DOGq. Hence 7 G lexecs{A, L) by definition of 
lexecs(A, L). Thus p C lexecs{A, L). □ 
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Corollary 15 (Relative Expressive Completeness of Complemented-pairs) Let A be an 

automaton, and let ijj he an arbitrary robust live trace property for A. Then there exists a complemented- 
pairs liveness condition L over A such that traces {lexecs {A, L)) = ip. 

Proof. Let ip be an arbitrary robust live trace property for A. By Definition 21, there exists a 
robust live execution property ip for A such that ip = traces{(p). By Theorem 14, there exists a 
generalized-Buchi condition {Gj | i G ry} over A such that (p = {7 | Vi G rj : 7 \= OOGi}. Let 
L = {{true,Gi} \ i Erj}. Then lexecs{A, L) = ip. Hence there exists a complemented-pairs liveness 
condition L over A such that traces {lexecs {A, L)) = ip. □ 

8.2 Expressive Completeness of Complemented-pairs for Liveness Properties of 
Forest Automata 

An automaton A is a forest automxiton iff for each reachable state s of A, there is exactly one 
(finite) execution of A with last state s. Thus, if a, a' arc arbitrary different infinite executions of 
A, then they have only a finite number of states in common. Any automaton can be turned into a 
forest automaton by adding a history variable which records the execution up to the current state. 
While this is obviously impractical for a real implementation, such a variable is only needed for 
modeling and analysis purposes; it does not have to be implemented since it does not affect the 
actual execution of the automaton. 

Let a be an arbitrary infinite execution of A. Define pair{a) = {states (a), 

Proposition 16 Let A be a forest automaton. Then \/a,a' G execs'^ {A) : a! ^ a iff a! \= pair (a). 

Proof. Let a, a' be arbitrary elements of execs^{A). If a' ^ a, then a' \= OD-i stores (a), since a, a' 
have only a finite number of states in common. Hence a' ^ UOstates{a), and so a! \= pair{a). If 
a' = a, then a' \= COstates{a), and so a' ^ pair{a). □ 

We show that, if is a live execution property for automaton A, then there exists a liveness 
condition which expresses i.e. such that an execution satisfies every complemented-pair in the 
condition iff it is a member of ip. 

Theorem 17 (Expressive Completeness of Complemented-pairs for Forest Automata) 

Let A be a forest automaton, and let p be an arbitrary live execution property for A. Then there 
exists a complemented-pairs liveness condition L over A such that lexecs{A, L) = (p. 

Proof. If (/9 = execs'^ (A) then letting L = {{true , true)} establishes the theorem. Hence we 
assume that p is a proper subset of execs'^ (A) for the rest of the proof. Let L = {pair (a) \ a G 
execs^{A) — ip}. We show that lexecs{A, L) = p. The proof is by double-containment. 

lexecs{A, L) C (p: Choose arbitrarily a' G lexecs{A, L) and a G execs^{A) — ip. Now lexecs{A, L) C 
execs'^ (A) by definition, and so a' G execs'^ (A). Prom the definition of L, we have a' \= pair (a). 
Hence, by Proposition 16, a 7^ a' . Since a was chosen arbitrarily from execs'^{A) — (p, we conclude 

a' ^ execs^{A) — p. Hence a' G ip, since a' G execs^{A). 

p C lexecs (A, L): Choose arbitrarily a' G p and a G execs^{A) — p. Hence a 7^ a'. Hence, by 
Proposition 16, a' \= pair{a). Since a was chosen arbitrarily from execs''^{A) — ip., we conclude, 
from the definition of L, that a' G lexecs{A, L). □ 

^"The terms "ghost variable" and "auxiliary variable" have been used in the literature for this notion. 
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Corollary 18 (Expressive Completeness of Complemented-pairs for Forest Automata) 

Let A be a forest automaton, and let ip be an arbitrary live trace property for A. Then there exists 
a complemented-pairs liveness condition L over A such that traces {lexecs {A, L)) = ip. 

Proof. Let ip be an arbitrary live trace property for A. By Definition 4, there exists a live execution 
property ip for A such that = traces{(p). By Theorem 17, there exists a liveness condition L 
over A such that lexecs {A, L) = ip. Hence there exists a liveness condition L over A such that 
traces {lexecs {A, L)) = ip. □ 



The use of an infinite number of complemented pairs was proposed by Vardi [53], which defines 
a recursive Streett automaton to be one whose transition relation is recursive, and whose com- 
plemented pairs are defined by recursive sets. Recursive Buchi automata are defined similarly. 
Recursive Wolper automata are those with a recursive transition relation and no acceptance con- 
ditions. Every infinite run of the Wolper automaton is accepting. The paper shows that Recursive 
Wolper, Buchi, and Street automata all accept the same set of languages, namely S}. In our 
approach, we make no restrictions on the set of complemented pairs. For example, we allow un- 
countable sets of pairs, which could be useful for specifications over uncountable domains, e.g., the 
reals. 

The safety-liveness classification was first proposed in [27]. Formal characterizations of safety 
and liveness, variously based on Buchi automata, temporal logic, or the Borcl hierarchy, were 
given in [2, 37, 50]. Many researchers have proposed deductive systems for proving properties of 
infinite-state reactive and distributed systems, including liveness properties, e.g., [3, 28, 29, 38]. 
Some of the methods proposed to date incorporate diagrammatic techniques, similar in spirit to 
our complemented-pairs lattices. In particular, Owicki and Lamport [45] propose proof lattices, 
and Manna and Pnueli [36, 40] propose proof diagrams, both for establishing liveness properties of 
concurrent programs. In [41], Manna and Pnueli propose three different kinds of verification dia- 
grams, two for safety properties, and one for liveness properties of the form 0(U => ^V), where 
U, V are state- assertions, that is, temporal leads-to properties. Nodes in this diagram are labeled 
with state-assertions, and directed edges between nodes represent program transitions. Some of 
these edges correspond to "helpful" transitions, which are guaranteed to occur (using fairness) if 
execution enters their source node, and whose occurrence makes progress towards making V true. 
Browne ct. al. [8] and Manna ct. al. [35] present generalized verification diagrams, which can be 
used to establish arbitrary temporal properties of programs, including liveness properties. These 
are a particular kind of w-automaton ("formula automata"). These methods relate a program, 
expressed in an operational notation, to a property expressed in temporal logic, i.e., they relate 
two artifacts expressed in very different notations. Thus, they cannot be used to refine liveness 
properties in a multi-stage stepwise refinement method that, starting with a high-level specification, 
expressed in a particular (operational) notation, constructs a sequence of artifacts, all expressed 
in the same notation, and each a refinement of the previous one, and ending with the detailed 
implementation. 

Our complemented-pairs lattices relate a liveness property of an automaton, to a liveness prop- 
erty of a lower level automaton, i.e., the relationship is between two artifacts expressed in the same 
notation. This forms the basis for a multi-stage proof technique that refines high-level liveness 
properties down to the liveness properties of an implementation in several manageable steps (our 
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use of "sublattices" in Section 6 is an example of this). Furthermore, each indivudual refinement 
step is itself decomposed into the tasks involved in constructing lattices and discharging the associ- 
ated "verification conditions." We feel that this ability to decompose a liveness proof into multiple 
stages directly attacks the scalability problem, and is one of our main contributions. UNITY [9] 
provides a framework in which a subclass of general liveness properties, namely "leads-to" can be 
verified and refined. The approach is proof theoretic, and also relies on fairness. We showed in 
Section 7. 1 above how to deal with leads-to properties in our framework. All of the aforementioned 
methods operate only at the level of executions, and do not provide a notion of external behavior, 
such as a set of traces. 

Gawlick et. al. [17, 18] presents a proof method for liveness properties. In that paper, a liveness 
property of an automaton A is modeled as a subset L of the executions of A}^ However, the method 
presented there imposes a proof obligation concerning the liveness of individual executions, without 
providing any rule or method for discharging this obligation. Specifically, in addition to establishing 
a simulation, we have to show that if an execution a of the implementation A corresponds to an 
execution a' of the specification B, and a is live (i.e., a is a member of the liveness property), 
then a' is also live^^. Merely establishing a simulation between A and B is insufficient to show 
this, since the simulation relation makes no reference to the liveness conditions of A and B. The 
main concern in [17] is the interaction between liveness properties and parallel composition; a 
notion of "environment-freedom" is introduced which enables the use of compositional verification 
for liveness. The published version [18] omits the proof method. 

Likewise, Jensen [23] presents simulation relations for proving liveness properties, and also 
requires that an "inclusion" condition be verified. A difference is that the live executions are exactly 
the fair executions, and so the inclusion property becomes: if an execution a of the implementation 
A corresponds to an execution a' of the specification B, and a is fair, then a' is also fair (Theorems 
2.9 and 2.10 in [23]). 

Sogaard- Andersen, Lynch, and Lampson [51] presents a similar method, with the main difference 
being that the liveness property is given by a linear temporal logic formula. Now, the proof 
obligation is that if an execution a of the implementation A corresponds to an execution a' of the 
specification B, and a satisfies the liveness formula for A, then a' satisfies the liveness formula for 
B. 

Henzinger et. al. [21] presents various extensions of simulation that take fairness into account. 
Fairness is expressed using either Buchi or Streett (i.e., complemented-pairs) acceptance conditions. 
However, the fair simulation notions are defined using a game-theoretic semantics, and require a 

priori that fair executions of the concrete automaton have matching fair executions in the abstract 
automaton. There is no method of matching the Red and Green states in the concrete and ab- 
stract automata to assure fair trace containment. Also, the setting is finite state, and the paper 
concentrates on algorithms for checking fair simulation. 

Alur and Henzinger [4] proposes the use of complemented-pairs acceptance conditions to define 
liveness properties. However it restricts the conditions to contain only a finite number of pairs. 
As our example in Section 6 shows, it is very convenient to be able to specify an infinite number 
of pairs — in this case, we were able to use two pairs for each operation x submitted to the data 
service, one pair to check for response, and the other to check for stabilization. It would be 
quite difficult to specify the liveness properties of the data service using only a finite number of 
pairs. If however, the system being considered is finite-state, then we remark that much of the 

^^L must satisfy the machine closure constraint of Definition 5. 
^^See [17], page 89. 
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work on temporal logic model checking seems applicable. For example, the algorithm of Emerson 
and Lei [13] for model checking under fairness assumptions can handle the complemented-pairs 
acceptance condition. While [4] gives rules for compositional and modular reasoning, it does not 
provide a method for refining liveness properties. As stated above, we believe this is a crucial aspect 
of a successful methodology for dealing with liveness. It should be clear that Figure 5 provides a very 
succinct presentation for the refinement of the liveness property expressed by {x G wait,x ^ wait), 
namely that every request eventually receives a response. 

Our work is in the linear-time setting, where the external behavior is a set of traces. In the 
branching-time setting, the external behavior can be given as a "trace-tree" [21], i.e., a tree whose 
branches are traces. Our liveness-preserving simulation relations should imply an appropriate 
containment notion between "live-trace-trees," i.e., a tree whose branches are live traces. However 
we point out technical differences between our setting and [4, 21]: we abstract away states and 
internal actions to obtain traces, whereas in [4, 21] an execution is a sequence of states (actions are 
not named) , and a trace is obtained by applying an "observation function" to each state along the 
execution. 

Kesten, Pnueli, and Vardi [24, 25] present a method of finitary abstraction: construct a finite- 
state abstraction ("abstract system") of an infinite-state "concrete" system, and model check this 
abstraction for the required properties. The method deals with properties expressed in full linear 
time temporal logic, (and so handles both safety and liveness), and is complete, i.e., a suitable finite 
state abstraction can always be constructed. The semantics of the concrete system is given by a Fair 
Discrete System (FDS), which consists of (1) a finite set of typed system variables, containing the 
data and control state (the concrete variables), (2) a predicate giving the set of initial states, (3) a 
predicate giving the transition relation, (4) a justice condition; a finite set of predicates {Ji, J^}, 
where each Jj must hold infinitely often along a computation, and (5) a compassion condition, 
a finite set of pairs of predicates {< pi,qi >,....,< PmQn >}; along a computation, if pi holds 
infinitely often, then qi must hold infinitely often. The justice and compassion conditions ensure 
that the concrete system satisfies liveness properties by restricting attention to "fair" computations. 
For a given concrete system, a finite-state abstract system is specified syntactically, by giving a 
set of abstract variables (with finite domains), and for each abstract variable, giving its value 
as an expression over the concrete variables. This implicitly defines a mapping from concrete to 
abstract states, and gives rise to two abstraction operators on concrete predicates: (1) a universal 
(contracting) abstraction, that holds in an abstract state iff the concrete predicate holds in all 
corresponding concrete states, and (2) an existential (expanding) abstraction, that holds in an 
abstract state iff the concrete predicate holds in some corresponding concrete state. The (concrete) 
temporal properties to be verified are abstracted by distributing these operators through temporal 
modalities (nexttime, until) and disjunction. Distribution through negation converts a universal 
abstraction into an existential one, and vice-versa. The abstract system is obtained by applying 
existential abstraction to the initial state predicate and each justice predicate. The transition 
relation is abstracted by "lifting" it to the abstract level using the definitions of the abstract 
variables in terms of the concrete variables. The compassion pairs <pi,qi > are abstracted by 
applying universal abstraction to pi and existential abstraction to g^. A main result is that if the 
abstracted system satisfies the abstracted property, then the concrete system satisfies the concrete 
property. Another main result is that the method is complete: if the concrete system satsifies the 
property, then there exists a corresponding finite state abstract system and abstracted property 
such that the abstract system satsifies the abstract property. To obtain completeness, the concrete 
system must be "augmented" by composing it (synchronously) with a "ranking monitor," which 
tracks the difference in successive values of a variant function ("progress measure" in the paper) 
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that decreases with progress towards satisfying the hveness property, and is defined over a weh- 
founded domain. The reason for incompleteness of the unaugmentcd method is liveness properties. 
A major difference with our approach is that the number of complemented pairs is finite, whereas 
we allow an infinite set. Furthermore, the abstract system in our approach is not necessarily finite 
state. Verification in our approach is by manually devising a liveness-preserving simulation relation, 
and the needed complemented pairs lattices, and then checking the conditions in the corresponding 
definitions, possibly with mechanization via theorem proving (see Section 7.3). Verification in 
[24, 25] is by manually devising the finitary abstraction mapping and the ranking monitors, and 
then model-checking the resulting abstracted system against the abstracted property. There is no 
method for deriving a liveness property at one level from other liveness properties at the same level, 
like our complementcd-pairs lattices provide. 

In [52], a method of abstraction based on Galois theory is presented. This is based on extensions 
of the framework of abstract interpretation [10] to temporal properties. Again, there are two 
abstraction notions: under-approximation and over-approximation. In [11], the interaction between 
abstraction and model checking under fairness is discussed. It is pointed out that abstraction really 
requires three- valued logic, since, e.g., a proposition that is true in one concrete state and false in 
another has "unknown" value in an abstract state that represents both concrete states. To handle 
fairness properly, two abstractions of the transition relation are introduced, called the free and 
constrained transition relations. 

10 Conclusions and Further Work 

We have presented five liveness-preserving simulation relations that allow us to refine the liveness 
properties of infinite-state distributed systems. Our method for refining liveness requires reasoning 
only over individual states and finite execution fragments, rather than reasoning over entire exe- 
cutions. Wc believe that the use of simulation-based refinement together with complemented-pairs 
lattices for expressing and combining liveness properties provides a powerful and general frame- 
work for refining liveness properties. In particular, our approach facilitates the decomposition of 
the refinement task at each level into simpler subtasks: devise the liveness-preserving simulation 
relation, and devise the complemented-pairs lattices. Since the lattices are a kind of diagram, they 
also facilitate the decomposition of proofs and the separation of concerns, which contributes to 
scalability of the method. 

The general approach and techniques used in this paper do not depend intimately on the par- 
ticular automaton model that we used. Thus, for example, our approach can be applied to labeled 

transition systems, which arc used to define operational semantics for process algebras such as 
Algebra of Communicating Processes [7], Communicating Sequential Processes [22], Calculus of 
Communicating Systems [42], and the vr-calculus [43]. Our approach can also be extended in a 
straightforward way to formalisms with unlabeled actions, such as (finite or infinite) Kripke struc- 
tures, since the fact that actions are named is not used in any essential way, it just contributes to 
the "matching" condition in simulation relations, and to the definition of external behavior (trace). 

We showed that the Streett acceptance condition (generalized to arbitrary cardinality) is ex- 
pressive enough to define any liveness property, provided that it satisfies a notion of robustness, or 
provided that history variables can be used. 

Simulation relations as a proof method for refinement have been widely studied. One major 
impediment to their widespread adoption in practice is the absence of efficient methodologies for 
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establishing simulation relations. Doing so usually requires long proofs, with many invariants, etc. 
Some of the ideas in this paper may be applieable to decomposing and simplifying the task of 
establishing simulation relations in the first place. For example, it may be possible to apply our 
approach to refining the invariants that are used in such proofs. Another potential application 
is to models of computation for dynamic [6], real-time [31], hybrid [32], and probabilistic [49] 
systems. For example, a real-time analogue of a complemented-pair condition would be: if a Red 
state occurs, then a Green state must occur within t time units. A complemented-pairs lattice that 
refines a complemented-pair would then have to satisfy, in addition to the current requirements 
of Definition 17, a condition for the time bounds: every path from the bottom element to the 
top element should have a "total" time bound matching the pair being refined. In [6], we present 
an automata-theoretic model for dynamic computation, in which individual processes (automata) 
that constitute a system can be created and destroyed, and can dynamically change their action 
signature. Since the techniques of this paper assume only a generic automaton structure, they are 
applicable to the model of [6]. Combining these two pieces of work will result in a comprehensive 
method for verifying the liveness properties of dynamic systems. 
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A Simulation Relations 



We present here five simulation relations, using the definitions of [34]. 

Definition 22 (Forward Simulation) Let A and B he automata with the same external actions. 
A forward simulation from A to B is a relation f over states{A) x states{B) that satisfies: 

1. If s e start{A), then f[s] n start{B) / 0. 

2. If s — s' and u €z f [s] , then there exists a, finite execution fragment a of B such that 
fstate{a) = u, lstate{a) G f[s'], and trace{a) = trace{a). 

Simulation based proof methods typically use invariants to restrict the steps that have to be 
considered. An invariant of an automaton is a predicate that holds in all of its reachable states, or 
alternatively, is a superset of the reachable states. 

Definition 23 (Forward Simulation w.r.t. Invariants) Let A and B be automata with the 

same external actions and with invariants I a, Ib, respectively. A forward simulation from A to B 
with respect to I a and Ib is a relation f over states{A) x states (B) that satisfies: 

1. Ifse staH{A), then f[s] n start{B) ^ 0. 

2. If s-^As' , s € I A, and u G f{s] D Ib, then there exists a finite execution fragment a of B 
such that fstate{a) = u, lstate{a) G f[s'], and trace{a) = trace{a). 

We write A <f B if there exists a forward simulation from A to B w.r.t. some invariants, and 
A <F B via / if / is a forward simulation from AtoB w.r.t. some invariants. 

Definition 24 (Refinement Mapping w.r.t. Invariants) Let A and B be automata with the 
same external actions and with invariants I a, Ib, respectively. A refinement mapping from A to 
B with respect to I a and Ib is a function r from states (A) to states {B) that satisfies: 

1. If s e start{A), then r{s) G start{B). 

2. If s -^A s' , s G Ia, and r{s) G Ib, then there exists a finite execution fragment a of B such 
that fstate{a) = r{s), lstate{a) = r{s'), and trace{a) = trace{a). 

Wc write A <r B if there exists a refinement mapping from A to B w.r.t. some invariants, and 
A <ji B via r if r is a refinement mapping from ^4 to -B w.r.t. some invariants. 

Definition 25 (Backward Simulation w.r.t. Invariants) Let A and B be automata with the 
same external actions and with invariants I a, Ib, respectively. A backward simulation from A to 
B with respect to I a and Ib is a relation b over states{A) x states{B) that satisfies: 

1. Ifse Ia, then b[s] HIb^^. 

2. Ifse start{A), then b[s] Ib Q start{B). 
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3. If s s' , s G I A, and u' G b[s'] fi Ib, then there exists a finite execution fragment a of B 
such that f state (a) G b[s] HIb, lstate{a) = u' , and trace{a) = trace{a). 

A backward simulation b w.r.t. invariants is image-fi,nite iff for each s G states{A), b[s] is a finite 
set. We write A <b B if there exists a backward simulation from A to B w.r.t. some invariants, 
and A <b B via 6 if 6 is a backward simulation from AtoB w.r.t. some invariants. If the backward 
simulation is image-finite, then we write A <iB B, A <iB B via b, respectively. 

Definition 26 (History Relation w.r.t. Invariants) Let A and B be automata with the same 
external actions and with invariants I a, Ib, respectively. A history relation from A to B with 
respect to I a and Ib is a relation h over states (A) x states{B) that satisfies: 

1. h is a forward simulation from A to B w.r.t. I a and Ib- 

2. is a refinement from B to A w.r.t. Ib and Ia- 

We write A <h B if there exists a history relation from Ato B w.r.t. some invariants, and A <h B 
via ^ if ^ is a history relation from AtoB w.r.t. some invariants. 

Definition 27 (Prophecy Relation w.r.t. Invariants) Let A and B be automata with the same 
external actions and with invariants I a, Ib, respectively. A prophecy relation from A to B with 
respect to I a and Ib is a relation p over states{A) x states{B) that satisfies: 

1. p is a backward simulation from A to B w.r.t. I a and Ib- 

2. p~^ is a refinement from B to A w.r.t. Ib and Ia- 

A prophecy relation p w.r.t. invariants is image-finite iff for each s G states{A), p[s\ is a finite 
set. We write A <p B if there exists a prophecy relation from AtoB w.r.t. some invariants, and 
A <p B via p if p is a prophecy relation from ^ to -B w.r.t. some invariants. If the prophecy 
relation is image-finite, then we write A <ip B, A <ip B via p, respectively. 
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B Linear-time Temporal Logic 



We define the syntax and semantics of the temporal logic that we use as follows. This is essentially 
linear-time temporal logic without the until and nexttime operators. 

Definition 28 (Syntax of Linear-time Temporal Logic) The syntax of a linear-time tempo- 
ral logic formula is given inductively as follows, where /, g are sub-formulae, and U is a set of states 
{which defines a state-assertion): 

• Each of U, f A g and ^f is a formula 

• Cf is a formula which intuitively means that f holds in every state of the execution being 
considered 

• Of is a formula which intuitively means that f holds in some state of the execution being 
considered 

Formally, we define the semantics of linear-time temporal logic formulae with respect to an 
infinite execution, that is, an infinite sequence of states. 

Definition 29 (Semantics of Linear-time Temporal Logic) We use the usual notation to in- 
dicate truth: a \= f means that f is true of execution a. We define j= inductively, where 
a = S0S1S2 ... is an infinite sequence of states, and a' = SiSj+i . . . is the suffix of a starting 
in Si. 



a 




iff 


soeU 


a 




iff 


it is not the case that a \= f 


a 




tff 


a \= f and a \= g 


a 




iff 


for all i>0,a^\=f 


a 


HO/ 


iff 


for some i > 0, \= f 



In particular, a \= □<>/ meains that a* [= / for an infinite number of values of i. 
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C I/O Automaton Code for the ESDS Example, from [14] 



I/O Automaton Users 
Signature 

Input: 

response(x, w), where x € O and v €V 
Output: 

request(a;), where x € O 

State 

requested, a subset of O, initially empty 

Actions 

Output request(a;) Input response (x, u) 

Pre: x.id ^ requested.id EflF: None 

x.prev C requested.id 
EfT: requested <— requested U {x} 



Figure 7: The Users Automaton 
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I/O Automaton ESDS-I 



Signature 

Input: 

request(a;), where x & O 
Output: 

response(a;, u), where x € O and v SV 
Internal: 

enter(a;, new-po), where x £ O and new-po is a strict partial order on I 
stabilize(a;), where x £ O 
calculate(a;,?;), where x £ O and v £V 

add_constraints(neui-po), where new-po is a partial order on T 
State 

wait, a subset of O, initially empty; the operations requested but not yet responded to 

rept, a subset oi O x V, initially empty; operations and responses that may be returned to clients 

ops, a subset of O, initially empty; the set of all operations that have ever been entered 

po, a partial order on X, initially empty; constraints on the order operations in ops are applied 

stabilized, a subset of O, initially empty; the set of stable operations 



Actions 

Input request(a;) 

Eff: wait <— wait U {x} 

Internal enter(a;, new-po) 
Pre: x € wait 
X ^ ops 

x.prev C ops.id 

span{new-po) C ops.id U {x.id} 
po C new-po 
CSC{{x}) C new-po 
{{y. id, x.id) : y 6 stabilized} C new-po 
Eff: ops «— ops U {x} 
po «— new-po 

Internal add_constraints(raei«-po) 
Pre: span(new-po) C ops.id 

po C new-po 
Eff: po <— new-po 



Internal stabilize(a:) 
Pre: x 6 ops 

X ^ stabilized 



Eff: 



V{/ e ops, y xy X <po y 
ops\^^^x C stabilized 
stabilized <— stabilized U {a;} 



Internal calculate(x, u) 
Pre: x 6 ops 

X. strict a; € stabilized 

V € valset{x, ops, -<po) 
Eff: if a; G uiait then rept <— rept U {(a;, ii)} 

Output response(a;, ?j) 
Pre: (a;, v) € rept 

X £ wait 
Eff: wait <— uiaii — {a:} 

rept <— repf — {(a;,!;') : (a;,^;') £ rept} 



Figure 8: The Specification ESDS-I 



Internal enter(a;, new-po) 
Pre: x £ wait 

x.prev C ops.id 

span{new-po) C ops.id U {a;. id} 
po C new-po 
CSC{{x}) C new-po 
{(y. id, a;. id) : y £ stabilized} C new-po 
Eff: ops <— ops U {x} 
po *— new-po 



Internal stabilize(a;) 

Pre: x £ ops 

Vy £ ops, y <po xy X <po y 
-<po totally orders ops|^p„x 

Eff: stabilized <— stabilized U {a;} 



Figure 9: The Specification ESDS-II. Only differences with ESDS-I are shown. 
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I/O Automaton Frontend{c) 
Signature 

Input: 

request(a;), where x £ O and c = client(x) 
receiverc(j^ra), where r is a rephca and m G Mresp 
Output: 

response(a;, w), where a; £ O, c = client{x), and v £V 
sendcr-(m), where r is a rephca and m € Mreq 

State 



Input receiverc(( "response" , x, v)) 

EfT: if a; 6 waitc then rept^ -t— rept^ U {(x, ii)} 

Output response(a;, i;) 

Pre: {x, v) £ rept^ 

X £ waitc 
Eff: jwaitc <— waifc — {a:} 

rept^ <— repig — : {x,v') £ rept^} 



waitc, a subset of O, initially empty 
reptc, a subset of O x initially empty 

Actions 

Input request(a;) 

Eff: waitc *— waitc U {x} 

Output sender ({ "request" , a;)) 
Pre: x £ waitc 
Eff: None 



Figure 10: The Automaton for the front end of client c 
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I/O Automaton Replica{r) 



Signature 

Input: 

(m), where c is a client and m € Alreg 
receivej./^(m), where r' r is a repUca and m € Mgossip 
Output: 

sendr-c(Tn), where c is a chent and m € Mresp 
sender' ('Ti), where r' ^ r is a replica and m € ^A.gossip 
Internal: 

doJtr(a;, /), where x € O and I € £r 
State 

pending^, a subset of O, initially empty; the messages that require a response 

rcvdr, a subset of O, initially empty; the operations that have been received 

doner [i] for each replica i, a subset of O, initially empty; the operations r knows are done at i 

stablcrli] for each replica i, a subset of O, initially empty; the operations r knows are stable at i 

labelr : I ^ CU {oo}, initially all oo; the minimum label r has seen for id &X 

Derived variable: Icr = {{id, id') : labelr{id) < labelr{id')}, a strict partial order on X; the local constraints at r 



Actions 

Input receivecr(("request" , x)) 
Eff: pending^ <— pending^. U {a;} 
rcvdr <— rcvdr U {x} 

Internal do_itr(a;,Z) 
Pre: x g rcvdr — doner[r] 

x.prev C duner[r].id 

I > labelr (y -id) for all y £ doner[r] 
Eff: doner[r] ^ doner[r] U {x} 

labelr{x.id) <— I 



Output sendrc(("rcsponse" , x, v)) 
Pre: x g pending r n doner [r] 

X. strict X £ stabler[i] 
v g valset(x, doner[r], -<icr) 
c = clientix) 
Eff: pending^. ^ — pending..^. — {;/■} 



Output send^^/(("gossip" , R, D, L, S)) 
Pre: R = rcvdr; D = doner[r]\ 
L = labelr', S = stabler[r\ 

Input receiver/^(( "gossip", R, D, L, S)) 
Eff: rcvdr <— rcvdr U R 

doner[r'] ^ doner[r'] UDU S 

doner[r] <— doner[r] U D U S 

doner[i] <— doner[i] U S for all i ^ r,r' 

labelr <— nain^labelr, L) 

stabler[r'\ <— stabler[r'\ U S 

stabler{r\ *— stabler{r\ U 5 U (f~lj doner{i\) 



Figure 11: Automaton for replica r 
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I/O Automaton Channel{i,j,M) 
Signature 

Input: 

sendij{m), where m € M 
Output: 

receiveij(m), where m € M 

State 

channelij, a multiset of messages, (taken from M), initially empty 

Actions 

Input sendij(m) 

Eff: channelij *— channelij U {m} 



Figure 12: The Channel Automaton 



Output receiveij(m) 
Pre: m e channelij 
Eff: channelij channelij — {^} 



54 



